BMC AMI DevX Reviews

BMC AMI DevX is used primarily for mainframe application development and troubleshooting, particularly for COBOL and JCL. I use it to edit and navigate code, browse datasets, and submit jobs, and also to debug application issues.

One example is when a COBOL batch job fails with a SOC7 data exception. I first check the job output and abend details to identify the calling program and statement. Then I use BMC AMI DevX to step through the COBOL program and check the variable values at the point of failure and trace the program flow. This helps me determine whether invalid numeric data or a specific piece of program logic caused the issue. Once I identify the root cause, I make the required changes, test them, and then follow the normal change and deployment process.

BMC AMI DevX has had a positive impact mainly by improving developer productivity and making mainframe development more accessible. The modern development environment reduces the need to switch between multiple tools for activities such as editing COBOL, browsing datasets, submitting jobs, and debugging. It also helps with newer development work where we work with legacy applications, as experienced developers transition away from traditional green screen workflows. Overall, it has made development and troubleshooting more efficient and provides a more modern way of working with existing mainframe applications.

The clearest measurable impact is faster troubleshooting and faster debugging. For issues where BMC AMI DevX is applicable, the debugging time has been reduced by 20 to 30% mainly because I can step through the COBOL program and check variable values. It has reduced manual effort by bringing code analysis and debugging into a more interactive experience.

The most valuable feature is the integrated COBOL debugging and code analysis capability. Being able to step through programs, set breakpoints, and monitor variable values to understand how the program flow operates makes troubleshooting much easier and more structured. I also appreciate the modern development environment for editing COBOL, browsing datasets, and submitting JCL jobs without constantly switching between different tools. The code navigation and AI-assisted code understanding capabilities are also useful for working with unfamiliar legacy applications.

The code understanding features have been useful when I need to work with unfamiliar COBOL applications. They help me explain existing code, identify the relationships and dependencies between programs and copybooks, and make it easier to understand the overall program flow. Instead of manually tracking every section of a large legacy application, I can use the AI assistance to get a quicker understanding of what the code is doing and where a change may have an impact. This reduces the time to get familiar with older code and makes maintenance and troubleshooting more straightforward and efficient.

I would suggest making the initial installation and configuration simpler, especially for new users. The login and startup experience could also be improved by reducing repeated login prompts and the time it takes for the application to become ready. I would like better integration between debugging and related information such as JCL, job output, abend details, and application logs. A more intuitive interface, stronger documentation website, and an easier onboarding process would also be beneficial. Additionally, enhanced AI-assisted capabilities would make the product easier to adopt.

I have been using BMC AMI DevX for about one year.

BMC AMI DevX feels stable in my experience.

BMC AMI DevX is good in terms of scalability. From my experience, it has been scalable for our mainframe development and support needs, handling large COBOL programs and large workloads.

The customer support is responsive when issues are raised and takes technical cases seriously. In our environment, some requests are routed through our internal support or mainframe team rather than directly to BMC, but issues are still handled through appropriate channels. I have a positive impression of the support experience. I would rate the customer support 9 out of 10.

We did not use any other solution before this. We were using mainframe tools before BMC AMI DevX.

For issues where BMC AMI DevX is applicable, I have seen debugging time decrease by around 20 to 30% because I can trace the COBOL programs and also inspect the variables. We can also identify the failing statement more efficiently, so the debugging time has been reduced by 20 to 30%.

I do not have direct information about the setup cost and pricing and licensing. From the implementation perspective, I think the initial configuration can require some effort to align the product with existing enterprise processes and mainframe tooling.

We did not see many options, but we primarily relied on standard mainframe tools such as ISPF and SDSF, and we used to do manual tracking of COBOL.

BMC AMI DevX provides a strong modern development and debugging experience for mainframe applications. I rate it in the range of 8 to 9 out of 10. What keeps it from being a 10 is mainly user experience, as the login and startup process can be frustrating, and the initial setup can also be challenging for new users.

I have a positive view of the security around BMC AMI DevX in an enterprise environment. However, I have not personally evaluated the underlying governance controls of its AI capabilities in detail. For AI-assisted code understanding, I want clear controls around access to source code and link data and permissions, as well as understanding how AI-generated explanations are processed. These areas would be important considerations before using the AI features with sensitive or business-critical mainframe code.

I find that the AI-assisted code understanding and output generated through BMC AMI DevX is useful and generally reliable for getting an initial understanding of unfamiliar COBOL applications. It can explain code, identify dependencies, and clarify program flow, which saves time when working through legacy code. However, I treat AI output as a starting point rather than the final authority, especially for business-critical logic, and I still validate the explanation against actual code and application behaviors before making any changes.

BMC AMI DevX is deployed in a hybrid cloud in our organization and integrates with our existing mainframe environment. IBM is the cloud provider for our hybrid cloud deployment.

My advice would be to evaluate BMC AMI DevX against the specific needs of your mainframe development team. If you work extensively with COBOL and want to modernize development, debugging, and DevOps workflows, it is worth considering. I would recommend running a full proof of concept with your applications and involving both experienced and newer developers. Pay particular attention to integration with existing source control, CI/CD, and security processes. Also, plan for some initial configuration and provide hands-on training so the team can get comfortable with the platform. My overall rating for BMC AMI DevX is 8 out of 10.

I work on mainframe, and some of the developers prefer to code on BMC AMI DevX because it looks more modern. For me, my basic use of it is just to extract information. Most of the time we end up having to extract certain files from the mainframe. Because those files use copybooks, the only way to extract the file in a certain layout using a specific copybook is through the use of BMC AMI DevX. I log in to the mainframe dataset and then browse using File-AID, but I'm using BMC AMI DevX application. I use it mainly for file extracts on my side and also to browse and do edits on files. Some of the other developers also do code on it. They do prefer to write code on it, but I still prefer the green screen.

I definitely think BMC AMI DevX could be improved or enhanced in terms of the logging in features. BMC AMI DevX's logging in feature is not so great. Whenever you try to log in, it always prompts you for passwords. Then when you have to switch sessions, because we usually have to switch between production and UAT, there's no quick way of switching between the two. Every time you try to switch, it prompts you to log in. Additionally, there's a pop-up that I always receive. When you click X on it, it doesn't disappear. Eventually, I just end up minimizing it. Furthermore, the startup of BMC AMI DevX takes a long time to start up before it loads. It doesn't just immediately start up and it's ready. It takes a good solid two to three minutes before it's ready so that you can work on it.

I would definitely say the features of BMC AMI DevX, specifically the speed, the extraction speed, have been the most useful. It's very quick compared to extracting a certain file directly from the mainframe itself. With mainframes, we deal with huge volumes of files or huge sizes of files. With BMC AMI DevX, when it comes to extracting, you just browse it, it quickly loads it with the exact layout as is. Then when you try to export the file to a CSV or to an Excel format, you just say export and immediately it's done. You don't even wait. On the other side, with the mainframe, you can do the very same file and it ends up taking 15 or 20 more minutes long. In some cases, it never even finishes extracting and it complains about the sizes. I don't encounter the same problem with BMC AMI DevX.

BMC AMI DevX's tools have affected my developers' productivity and efficiency by helping with the speed. It makes you more productive because now you're able to achieve more things quicker instead of struggling with trying to find other ways on mainframe. It helps you develop faster, produce files faster, and extract files faster.

I definitely think BMC AMI DevX could be improved or enhanced in terms of the logging in features. BMC AMI DevX's logging in feature is not so great. Whenever you try to log in, it always prompts you for passwords. Then when you have to switch sessions, because we usually have to switch between production and UAT, there's no quick way of switching between the two. Every time you try to switch, it prompts you to log in. Additionally, there's a pop-up that I always receive. When you click X on it, it doesn't disappear. Eventually, I just end up minimizing it. Furthermore, the startup of BMC AMI DevX takes a long time to start up before it loads. It doesn't just immediately start up and it's ready. It takes a good solid two to three minutes before it's ready so that you can work on it.

BMC AMI DevX's logins and the other ones I can understand because security has to be there, but I do feel that once I've logged in, I shouldn't need to log in again. The startup problem is the annoying one because if I want to do something, I need to open it two or three minutes earlier to give it time to load up. The startup problem is the one that definitely needs to be addressed.

I started using BMC AMI DevX from last year in January.

I think BMC AMI DevX is very stable. BMC AMI DevX is very stable for a modern application processing huge workloads. I've also seen some of the developers where they are able to compile huge amounts of code, which includes COBOL programs with a lot of lines. It produces reliable results there. I've never seen it complain about the huge amount of code that it has to read and compile. Even when I do extract files on my side, when I usually have issues extracting a huge amount of files on the mainframe, I don't encounter those problems with BMC AMI DevX.

From my perspective, I haven't seen BMC AMI DevX struggle in terms of workloads where it needs to be scaled up or scaled down. So far, based on what I've seen and using it, I haven't been at a point in time where I'm thinking that we need to scale up or we need more processing power from it. I think it's been very reliable. We haven't had the need to scale up or scale down from it.

I have not yet used the GenAI-powered code understanding features of BMC AMI DevX for COBOL or another language, unfortunately. I will definitely try and check them out.

I haven't used AI capabilities in BMC AMI DevX at all yet.

I have not leveraged the full-lifecycle Java support in BMC AMI DevX because we are strictly COBOL and we don't integrate with the other languages.

I've seen the Git features in relation to my use of z/Adviser, but because our CI/CD is through ISPW, we haven't used Git. We also don't use Git in our team specifically.

I think the hybrid CI/CD integration with existing enterprise DevOps tools in BMC AMI DevX is very good. When you do log into BMC AMI DevX, you are able to see all your datasets from the mainframe directly without having to do anything. You can see all your PDSs, all your folders, all your files. You don't have to log into something else again. You just log in once into BMC AMI DevX and everything is already there.

I do not often communicate directly with the technical support of BMC. I just know that whenever we have issues, we do contact our mainframe platform guys, and then they do contact BMC AMI DevX guys. We don't talk to them directly; we just contact our guys directly and then they will have the communications with the other external teams.

Before using BMC AMI DevX, I was strictly using the mainframe, which is the Flex Terminal terminal emulator. It was strictly that. I think we did at some point try to integrate VS Code, but it just created a lot of issues, then we just ended up saying, "Let's leave this thing."

I did not participate in the initial setup or installation of BMC AMI DevX. Unfortunately, by the time I arrived at the team, it was already there.

Before choosing BMC AMI DevX, there were no other options that we evaluated besides VS Code.

From that perspective, I don't think I can give input about the impact of automated DORA metrics tracking on my organization's decision-making processes because I don't participate most of the time in that department, which just checks how quick the jobs are run or what's the difference between the two. For that one, I don't think I have any input there.

I think BMC AMI DevX has provided overall benefits and a positive impact because I've seen a lot of developers, not just the new developers, but even the old developers. I'm very young, so I found a lot of old developers here that have been with the business for a while and have used the green screen their entire life. I've seen most of them also developing with BMC AMI DevX, migrating into the newer screen. They call it, "We are leaving the green screen," is what they say. They look at BMC AMI DevX as VS Code for COBOL developers, which is for us. I've seen it, not only from the old developers but even the young developers, I've seen most of them using it. I'm still in a process where I'm trying to do a sort of a hybrid style, use both. Where there's an advantage, I use this one, and where there's an advantage, I use that one. I do think it provides a more modern way of working with old technologies, with legacy systems. I think it's very good there. It's modernizing the legacy way of doing things, the mainframe.

I've gone to the official documentation or guides provided by BMC for BMC AMI DevX once or twice because I was still trying to find out more about it or what it is because when I landed, I didn't know what this workbench and BMC AMI DevX thing were. I did go to the website, but I didn't get the time to just go through everything. That's something I also need to do.

I think BMC AMI DevX's Open Borders approach is very good for maintaining my existing processes. I think it's very good in terms of its ability to integrate smoothly with the mainframe or the other applications. For that reason, I think its effect is very good. It's a very good effect because it doesn't disrupt existing processes or any of the existing applications. Instead, it sort of helps or integrates perfectly with them without disrupting. For example, if I was to go into a dataset with BMC AMI DevX and make changes, and then someone else logs on to the mainframe and tries to view those, they're also going to be able to pick them up. It's not that now I have to wait for something to happen or need to save on that side. It integrates smoothly, so everything just works smoothly and seamlessly.

Based on my experience with every aspect of BMC AMI DevX, I would rate this product an eight because I still feel there is room for me to explore on it, but so far from what I've seen, it's very good and it definitely has a huge amount of potential.

One example is when a COBOL batch program fails in production and I need to identify the exact issue. I use BMC AMI DevX mainly for debugging and analyzing the program flow. I start by checking the job output and abend details to understand where the failure occurred. Then I use the debugging capabilities to trace the COBOL program, check the values of variables at the point of failure, and follow the program flow to identify which piece of logic caused the problem.

Sometimes I get SOC7 data exceptions. I check the failing statement and the related data field to determine whether invalid numeric data was received. Once I identify the root cause, I make the required code or data correction through the normal change process, test it, and then promote the fix. So I mainly use BMC AMI DevX for debugging COBOL programs.

In a real-time example, when a batch job fails with a SOC7 abend, I check the job output and identify the failing program and statement. Then I use DevX to debug the program, check the variable values and data at the point of failure, and trace the program flow to find the root cause. After identifying the issue, I make the required fix, test it, and follow the change and deployment process.

Apart from debugging, I also find it useful for understanding existing COBOL programs and troubleshooting production issues. When I am working on a change, I can follow the program flow and check how data is moving between different sections and variables. It helps me understand the impact of a change before making code modifications. Overall, I use BMC AMI DevX mainly for debugging, code analysis, and faster root cause identification.

Mainly I use BMC AMI DevX when I need to debug and analyze COBOL programs. I start by checking the job output in SDSF to identify the failing program and statement, and I use DevX to step through the program, check variable values, and understand the program flow.

In my experience, the most useful features are the debugging capabilities, especially being able to step through COBOL programs, monitor variables, and understand the program flow. I also find the ability to identify the exact statement where an issue occurred very useful for production troubleshooting. Another useful aspect is that it helps me analyze existing code more efficiently. Overall, the main benefit for me is that it makes debugging more structured and reduces the time needed to identify the root cause of an issue.

The features I find most useful are source-level debugging and breakpoints, variable monitoring, program flow analysis, abend analysis and troubleshooting, code analysis, and interactive debugging. Overall, I find these features useful for faster root cause analysis, especially when troubleshooting COBOL programs in a mainframe environment.

One improvement I would appreciate is stronger integration between DevX debugging and other troubleshooting information, such as JCL, job output, abend details, and application logs, all in one place. It would also be useful to have more automated root cause suggestions for common abends like SOC7 and SOC4. That could reduce the amount of manual analysis and make production troubleshooting even faster. Overall, the current debugging capabilities are useful, but better integration and automation would make the experience more efficient.

One thing that stands out for me is the combination of debugging and code analysis capabilities. Being able to step through the COBOL program, set breakpoints, and monitor variable values gives me a much clearer picture of what is happening during execution. One feature I would find useful is an even deeper integration with production diagnostics where job logs, abend information, source code, and debugging could be brought together in one place. That could make production troubleshooting even faster. Overall, the debugging and analysis features are the ones I find most valuable in my daily work.

If I could suggest improvements, I would focus on making the user experience more intuitive, expanding practical documentation, and providing deeper integration between debugging, JCL, job output, and diagnostic information. Those additions would make an already useful tool even more convenient for mainframe developers and support teams.

I have around 3.4 years of experience in the mainframe field. Regarding BMC AMI DevX specifically, I have been exposed to its tools in the mainframe environment for almost 3 years.

BMC AMI DevX has been stable for my day-to-day mainframe development and debugging activities. I have not experienced major stability issues during normal use. It has been reliable for COBOL debugging, code analysis, and troubleshooting production incidents. Of course, stability can also depend on the organization's environment, configuration, and integration with other tools.

From a developer's perspective, I find BMC AMI DevX scalable for mainframe development and support workflows. It can support multiple developers for COBOL applications as they debug different problems without changing the overall development process. I don't have visibility into the organization's infrastructure capacity or user volume metrics, so I can't provide specific scalability numbers. But from my day-to-day usage, it handles my development and troubleshooting needs.

Support requests go through my cross-functional team via the company's support channels, so I don't interact directly with BMC support very often.

We also relied on the standard mainframe tools and manual troubleshooting methods such as ISPF, SDSF, job logs, dumps, and manually tracing COBOL code. We moved to DevX mainly to make debugging and code analysis more efficient. I don't have access to the organization's purchase or migration data, so I can't provide application ROI or license cost details. From a developer perspective, the main visible benefit I have seen is that it reduced the time needed to debug by 20 to 30 percent for troubleshooting tasks where DevX is applicable.

I would estimate that the debugging time for issues where I used DevX was reduced by around 20 to 30 percent, mainly because I could directly trace the program, check variable values, and identify the failing statement. I wouldn't say it eliminated recurring issues because those depend on the actual root cause and quality of the fix. But faster root cause identification helped me resolve incidents more consistently and reduced the amount of manual debugging effort.

From a developer perspective, the main alternatives to the DevX workflow are the standard z/OS tools I already used, such as ISPF, SDSF, diagnostic dumps, and manual COBOL code testing or tracing. BMC AMI DevX provides a more interactive debugging experience than that workflow. I cannot speak about a hands-on comparison with other third-party tools.

I would recommend evaluating BMC AMI DevX based on the specific needs of the mainframe development team. If the team spends a lot of time on COBOL application maintenance and production troubleshooting, the debugging and code analysis capabilities can be particularly useful. I would also suggest starting with a small group of developers, providing some hands-on training, and measuring things such as debugging time and incident resolution effort before expanding usage. Overall, I would say it is worth evaluating, especially for teams looking to make mainframe development and application maintenance more efficient. I would rate this product an 8 out of 10.

My main use case for BMC AMI DevX is to work with COBOL and JCL development on IBM. I mainly use it for editing, browsing data sets, submitting jobs, and debugging applications. I appreciate the Eclipse and VS Code style interface compared to traditional ISPF, which makes navigation easier.

One specific example of how I used BMC AMI DevX in my day-to-day work is maintaining a COBOL-based mainframe application. I used the DevX workbench to edit COBOL programs, browse data sets, submit JCL jobs, and debug batch job failures. One issue involved a batch job that was failing because of incorrect output data. Using the integrated debugger and job output, I traced the problem to the validation routine in the COBOL program. I fixed the logic, resubmitted the JCL, and verified that the job completed successfully.

In my day-to-day work, I mainly use BMC AMI DevX to streamline the mainframe development workflow rather than switching between multiple tools. My typical routine includes editing COBOL programs, submitting JCL jobs, reviewing job output, debugging failures, and browsing data sets from a single environment. I also use it to integrate debugging failures to trace program execution and identify logic or data issues more quickly. Overall, it reduces context switching and makes troubleshooting and code maintenance more efficient, although the initial setup and learning curve are challenging.

BMC AMI DevX helps me develop COBOL while juggling other responsibilities by bringing editing, debugging, job submissions, and code navigation into a single environment. This reduces context switching, allowing me to spend less time managing tools and more time on development, making it easier to balance COBOL work with my other responsibilities.

I have used the GenAI-powered code understanding features of BMC AMI DevX for COBOL, which helps me understand unfamiliar code much faster. The code navigation, dependencies analysis, and AI-assisted code explanation make it easier to see how different COBOL programs, copybooks, and JCL jobs are connected. Instead of tracing everything manually, I can quickly identify the program flow, understand business logic, and find where changes need to be made, significantly reducing the time it takes to get up to speed with legacy applications.

I have leveraged the full-lifecycle Java support in BMC AMI DevX for developing and maintaining Java applications that interact with mainframe services. The integrated debugging, code navigation, and monitoring tools make it easier to diagnose issues and application behavior across Java and mainframe. It is effective in troubleshooting because it allows me to quickly identify errors in variables and execution without switching between multiple tools, thus streamlining the development and debugging workflow.

The best features BMC AMI DevX offers are difficult for me to specify because I am using BMC AMI DevX in my day-to-day life.

A feature that surprised me about BMC AMI DevX is the Runtime Visualizer, which shows how programs interact at runtime, making it much easier to analyze application flow and troubleshoot dependencies.

BMC AMI DevX positively impacts my organization with its modern VS Code and Eclipse development environment, integrated debugging, AI-assisted code understanding, automated CI/CD pipelines, and end-to-end mainframe DevOps workflow.

Specific outcomes that show how BMC AMI DevX has positively impacted my organization include improvements in productivity, time saved, or reductions in errors. For instance, a Forrester Total Economic Impact study of organizations using BMC reported a 217% ROI, payback in under six months, and 26.2 million in benefits over three years for modeled enterprises with 300 mainframe developers. The study also found a 50% reduction in onboarding time for a new developer from about nine months to 4.5 months. Additionally, BMC highlighted customer examples such as reducing the efforts of moving changes from development to production from five hours to 18 minutes. I do not have firsthand organization metrics because I have not personally deployed BMC AMI DevX, but the published customer studies report improvements such as a 217% ROI, 50% faster onboarding, higher deployment frequency, and lower change failure rates, although I cannot claim those as my organization's results.

BMC AMI DevX is a strong platform, but there are a few areas where it could improve, such as simplifying the initial installation and configuration, especially for first-time users. It could also improve performance when working with very large mainframe applications or on slower network connections, and making the UI more intuitive so advanced features are easier to discover. These improvements would make the platform easier to adopt and more productive for both experienced mainframe developers and newcomers.

Regarding improvements needed for BMC AMI DevX, I would suggest making the UI more intuitive so advanced features are easier to discover and providing more built-in tutorials, guides, onboarding, and documentation for new developers.

I have been working for the last six months and completed an internship for about six months, so I have a total experience of one year.

BMC AMI DevX is very stable.

From what I have read, BMC AMI DevX appears to scale well for large enterprises, but I do not have personal experience running or managing it in a large-scale environment.

The customer support for BMC AMI DevX is very good.

I am not using a different solution before BMC AMI DevX.

The main challenges were the initial configuration and aligning the tooling with our existing enterprise processes.

I cannot say that I have personally seen a measurable return on investment because I was not involved in evaluating or deploying BMC AMI DevX in an organization. I do not have firsthand ROI data, but BMC has published customer studies reporting positive ROI, including a Forrester Total Economic Impact study that estimates a 217% ROI with payback in under six months for modeled enterprise deployments. However, those are published customer findings and not results from my own experience.

My understanding is that BMC AMI DevX is an enterprise product with custom licensing, so pricing is typically negotiated based on factors such as the modules purchased, organization size, and usage. I do not have direct experience with the commercial side or the total cost of ownership.

In evaluating options before choosing BMC AMI DevX, my organization considered various solutions in the market.

From what I have seen in the market, organizations evaluating BMC may also consider IBM Application Delivery Foundation for IBM Developer for z/OS, IBM Debugger, Debug for, and Broadcom Mainframe DevOps solutions. The product chosen usually depends on the existing mainframe environment, tooling, and DevOps strategies.

My advice to others looking into using BMC AMI DevX is to evaluate it against your organization's specific requirements rather than adopting it solely because of its feature list. If you are a large organization with COBOL applications and want to modernize development and DevOps workflow, it is worth evaluating. I recommend running a proof of concept with your own applications involving both experienced developers and newer developers, assessing integration with your existing source control, CI/CD, and security. Training is essential to get the most value from BMC AMI DevX. I would rate this product an 8.5 overall.

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 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 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 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.