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