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.
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.
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.
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.
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.
BMC AMI DevX is a mainframe DevOps platform for IBM Z environments that helps development and platform engineering teams increase release velocity, reduce change risk, and build a sustainable mainframe developer workforce. Whether the priority is attracting the next generation of mainframe talent, safely evolving decades of business-critical code, accelerating release velocity, or demonstrating development ROI to leadership — BMC AMI DevX is designed to address all on a single platform. Teams...
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.
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.
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.
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.
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.