BMC AMI DevX can be improved primarily by streamlining initial configuration and installation, simplifying advanced documentation, and enhancing UI/UX feature discoverability. While the platform successfully bridges modern IDEs such as VS Code with z/OS, user feedback highlights the need for simplifying setup and onboarding configuration. The initial installation and login process can be simplified. Although it feels complex initially, once completed, there is nothing to do with installation repeatedly since it is a one-time process. However, it is still somewhat complex.

Basic tutorials are available that address teams implementing the configuration of multi-vendor tools and integration, but documentation gaps exist that frequently force heavy reliance on vendor support. Additionally, certain components across the workspace and diagnostic tools retain a legacy feel or hide powerful features behind deep menus, so UI/UX features can be simplified.

Integrating with non-BMC enterprise testing or new CI/CD orchestrators can require custom engineering rather than native plug-and-play connectors. Optimizing large-scale performance is also important, as heavy resource consumption during deep runtime analysis for large-scale code mapping can impact performance over slower network connections for extremely dense application modules.

I would recommend some additional functionalities for debugging production failures, as while BMC AMI DevX already offers features like Ab-end AID for automatic detection and analysis of failures, a more comprehensible approach would be much appreciated. Additionally, reducing the product's cost for heavy volume users could be beneficial for corporates relying on this tool.

If BMC AMI DevX could be made functional for ETL or as a data engineering product, it would enable the data engineering team to leverage this tool and build their pipelines, which is currently not happening, thus stitching the data engineering and DevOps teams together.

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

An area for improvement in BMC AMI DevX would be the user interface and overall usability, which can feel a little complex for new users coming from modern development tools. Better documentation, easier navigation, and more intuitive workflows would reduce the learning curve, especially for occasional users.

Integration with newer DevOps and CI/CD tools could be improved further in BMC AMI DevX, especially for teams working with modern development pipelines. I would also like to see more troubleshooting guidance and practical examples in the documentation, so resolving common issues requires less dependency on support teams.

I rate BMC AMI DevX an 8 because the user experience can still feel less intuitive compared to modern development tools, especially for new users. I would also like to see stronger integration with modern DevOps and CI/CD workflows and more streamlined documentation.

I do not see any improvement needed for BMC AMI DevX, but the UI could be better as it looks a bit older for the modern world. Additionally, the visualization of the data being shown could be further improved so we can visualize things in a better way.

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.

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.

BMC AMI DevX can be improved by simplifying the user experience. BMC AMI portfolio contains multiple products and dashboards, so new users can face a steep learning curve. A more unified and intuitive interface would improve the adoption rate. I would also recommend the enhancement of the AI. The GenAI assistant is helpful, but our organization would benefit from more proactive recommendations. AI could automatically suggest fixes, generate runbooks, and predict release risks before deployment. Cost optimization is another area for improvement because BMC AMI DevX solution can require a significant investment. More flexible licensing and modular pricing could make adoption easier for smaller teams and departments.

An improved business dashboard would also help. It would help to demonstrate the ROI.

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.

If I consider improvements for BMC AMI DevX, I would like to see enhancements in the UI for a more seamless experience, especially given its slightly high licensing cost, where purchasing individual tools can be costly.

I believe the AI features are less mature at the moment and could definitely be improved.

I chose seven out of ten because the pricing and subscription model feels opaque, and I believe the AI-assisted code work has room for improvement.

I consider BMC AMI DevX to be pretty secure in terms of AI capabilities, but I feel a bit more transparency would enhance my understanding.

I find BMC AMI DevX reliable, but the level of detail in its output can certainly be improved.

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.

When it comes to the tool GUI for BMC AMI DevX, there are some places that I find hard to understand. For example, if you accidentally close some of the toolbars, it is difficult to track how to restore it, and that becomes a somewhat time-consuming process. This could be improved by creating a more simplified GUI so that anybody who uses it can easily learn it rather than view it as a very sophisticated system that requires more confidence to work with.

The configuration is also one of the issues that can be improved. The directories in which we store configuration sometimes exceed the space, or due to certain reboots or updates, those saves have been cleared out and it throws an error which requires us to manually create a new directory and configure everything from scratch. If it had a dedicated directory where it could, by default, run its cache or whatever configuration we keep, it would be very useful for us to act on during critical situations.

I choose eight out of ten because of two frustrating parts: one is the navigation complexity sometimes, and the other is the configuration that gets erased over reboots or cleaning of the saved directory configs. These need to be permanent and should not be stored somewhere else in the documents because VM teams often choose to clean them up over time.

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. 

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.

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. 

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.

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. 

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

At this time I do not know of additional improvements from my perspective.  Over the last year, Compuware has made major improvements to the JES Explorer, which used to be the biggest negative.

There are some tools in ISPF that are not available outside of ISPF right now, things the programmers may need to look at. They still have to go to the green screen for a few things.  Since we have the free version of Topaz, we do not have access to the new 3270 emulator that can handle this situation in Eclipse. 

We have noticed that Topaz supported Eclipse environments are rather old.  It would be nice if Topaz were compatible with the more current Eclipse releases.  The current version of Eclipse supported by Topaz is Photon.

One thing I would really like to see some improvement on is the promotion diagnostic messages. It invokes utilities "under the covers" to copy components, and it does not echo back any of the error messages from those utilities. So if we have an issue where, say, an old load module is missing an alias, it invokes IEBCOPY under the covers, and IEBCOPY returns a bad condition code. But there is nowhere that those messages are reported back to us. That's just a specific issue. 

In general, the logging and the message analysis, the output analysis, could be made easier to use.

There are some features that are not well documented, so documentation could use a little help, on things like setting up deployment and which structures in the database correspond to which tables. The admin configuration of it are kind of arcane. It would be nice if the doc were brushed up and maybe there were some step-by-step guides on doing things. There are some out there, but there are some things, like propagation, that are simply not documented and we don't even know how to set it up.

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.

My advice for new clients migrating to ISPW is to take the time needed to understand your current inventory of ASIs, code that is not executed/no longer required,  and any unique situations that may need to be handled differently than the standard migration approach.   This vendor is great in walking through different options and finding solutions for any special handling.   

Part of it is just getting used to using it. It's completely different from what I'm used to, going from a TSO interface to a GUI. I find it more cumbersome to use Topaz.

The ability to edit source code that has special characters is limited. 

The ability to incorporate or convert REXX into macros that are usable under the Topaz software is not there. And the REXX macros that I have developed over 40 years of work are useless, so I have a toolbox I can't use or deploy using the Topaz technology, while I can use it under MVS.

It's not as intuitive as it should be. In terms of navigation, there is a large training curve for using it. For a millennial it might be better, if they're used to Eclipse. But coming from a non-Eclipse environment and using Eclipse, though I have experience with Eclipse, it might be cumbersome. I still use the mainframe Xpediter, because I find it's less cumbersome to navigate to.

If Compuware resolves some of the issues of converting REXX into macros that are supported under the Topaz Edit function, the ability to support ISPF picture edits, and the ability to simulate some of the things that the mainframe can do on Topaz, that would be great.

I would look for more cooperation between the vendors and using Eclipse the way Eclipse is meant to be used. Topaz Workbench often doesn't play well with other plugins in the environment. It would be good if the vendors would work together or at least have some collaboration between them, so they would know what would work and what wouldn't work. Right now, the way things are working, they're relying on the customer to make everything work.

I would like to see the features include more integration or help customers when working with Jenkins. 

It would be nice to have an audit trail to see what mainframe developers are using what.

We are trying to get more people to use the product at the moment. I would like to expand its usage because it is a good product for development.

The area for improvement is related to the testing tools that are available for unit testing or acceptance testing. I know they have some out there that we are not licensed for at this time, but it seems like some of the Eclipse tools that are used for other programming languages, they're all just built-in and they're a little more intuitive to the developers. Making those testing tools as intuitive as possible, and as integrated as possible into the workbench, would be really beneficial.

• The ISPW plugin could be improved to add some functionality which is already in ISPF panels and not in the plugin. 
• It could also be improved to better help the developer manage merging versions in the life cycle (even if he can already use Eclipse merge view), and to have prompts on warnings and errors during generation and deployment, followed by a pop-up and before the promotion task.  

I'm always looking for improvement in things like the documentation, to make things a little bit easier and simpler to understand, a place where people can go to troubleshoot issues.

From an installation perspective, the simpler the installation of the product, the better. I always feel like there is room for improvement on installing. I've noticed, occasionally, installation steps could just be wrong, and that's very difficult for us. It extends the time it takes us to install the product. When we install it with the directions provided, and then it doesn't work, we have to open a ticket to find out why it doesn't work, only to find out that the documentation was missing a step. That is something that always needs to be reflected on, and has room for improvement.

Initial setup can be tricky in some cases. Also, there are some space limits that we would hit every now and then while processing internal tables, so we would have to decrease occurs clauses and re-test. These situations could have been related to how the shop installed Xpediter ... it might not be an issue with the tool itself.