BMC AMI DevX

A specific example of how I use BMC AMI DevX for mainframe app development is that we use it to automate builds and tests for COBOL apps, which cuts manual steps and speeds delivery.

BMC AMI DevX helps me develop COBOL while juggling other responsibilities by keeping builds predictable, so we can focus on other tasks.

The integration with our toolchain stands out because we tie it in with Jenkins and Git, and the integrations have been straightforward—nothing clunky, it just works.

BMC AMI DevX has positively impacted my organization with smoother releases, fewer build issues, and less time spent firefighting.

Specific outcomes I've seen include roughly 30% faster builds and far fewer failed jobs. The improvement is noticeable.

The hybrid CI/CD integration with existing enterprise DevOps tools is mostly smooth; Jenkins and Git integrate cleanly, though a bit more flexibility in reporting would help.

Measuring DORA metrics has helped improve our deployment frequency by roughly 20% and reduce change failure rates by around 15%, resulting in meaningful gains.

I have used the GenAI-powered code understanding features of BMC AMI DevX for COBOL, which has helped us understand unfamiliar code by summarizing logic, flagging dependencies, and helping us trace flow—providing quicker ramp-up and faster troubleshooting.

I have assessed the impact of automated DORA metrics tracking as useful, as it provides clearer visibility into deployment frequency, lead time, and success rates, making releases less gut-feel and more data-driven.

My advice for others looking into using BMC AMI DevX is to start with a clear automation plan, align CI/CD early, and lean on the vendor during rollout to save time. I would rate BMC AMI DevX an 8 out of 10 overall.

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.