BMC AMI DevX Reviews

My main use case for BMC AMI DevX is for a mainframe application where I use it for the code pipeline, streamlining and securing the building and deploying of the mainframe code files.

A specific example of how I use BMC AMI DevX in my code pipeline involves integrating it with my Visual Studio Code, which has helped me maintain the code pipeline using the CI/CD framework that my client uses for developing workflows around the mainframe application and deploying it for the client I worked on.

I have a few additional points about my main use case and how I use BMC AMI DevX day-to-day, which also involves using test data management and debugging, with File-AID and Abend-AID covering this for my application.

BMC AMI DevX has impacted my organization positively by providing advantages such as the code pipeline and code insights while identifying bottlenecks using Strobe, making my workflows easier as I previously lacked a tool that could assist me in these areas.

Regarding specific outcomes or metrics showing how BMC AMI DevX made my life easier, I mentioned the performance bottleneck identified on the scheduled job, from which I could analyze the timing breakdown during the wait time on each step, allowing me to leverage Strobe's features to identify and work on the mainframe applications efficiently.

BMC AMI DevX does help me in mainframe works while I juggle other responsibilities.

BMC AMI DevX tools have enabled me to save approximately 30 to 40% of the time due to its AI capabilities and seamless integration with my CI/CD pipelines.

The best features BMC AMI DevX offers, in my opinion, include the Strobe feature that finds performance bottlenecks while streamlining and securing the building of mainframe code using the code pipeline.

When it comes to finding performance bottlenecks, BMC AMI DevX has helped me identify a bad job that was calculating some billing information, where I saw the processing time grow from 40 minutes to two and a half hours, prompting me to schedule a Strobe measurement against the job to identify which step was taking more time, leading me to discover a memory issue with the CPU that I resolved by increasing my memory.

I would add that this was a standard use case with not much extra to discuss.

I have utilized the text-based GenAI feature of BMC AMI DevX; given that COBOL is a legacy language, it poses challenges in understanding the code base without AI, which certainly helps me work on it more promptly.

I find the hybrid CI/CD integration with my existing enterprise DevOps tools to be seamless, with no issues encountered.

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.

I have been using BMC AMI DevX for the past one or two years.

BMC AMI DevX is stable.

I find BMC AMI DevX to be scalable and capable of operating on any public, private, or hybrid clouds.

The customer support I have encountered is quite nice.

I don't know if I previously used any different solutions before BMC AMI DevX.

I don't have any information about the return on investment regarding money or time saved, or any resultant reductions in workforce.

I'm not sure if my organization purchased BMC AMI DevX through the AWS Marketplace, as I believe my leadership handled that aspect.

I don't have the exact numbers regarding pricing, setup cost, and licensing, but it was higher than what it should have been and there are transparency issues—it's opaque.

I believe my client did evaluate IBM tools prior to deciding on BMC AMI DevX.

My advice for others considering BMC AMI DevX is to carefully review the documentation and follow it as it will help in working with the tool in a standard way. I gave this review a rating of seven out of ten.

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.

BMC AMI DevX serves as our main tool for promoting to pipelines, such as dataset moves or map programs, and other JCL moves that we previously performed using Endevor. After migrating to Topaz Workbench, we started utilizing it for these purposes.

I can provide a specific example of how I use BMC AMI DevX in my workflow. We used to have JCL move components where we create a checkout, and then the next step would be to promote it from a specific stage, such as DF or DVF level, to another stage.

For maps, we previously used Endevor, but for the past four years, we have been using the DevX app exclusively for migration. We obtain components from our managers and handle deletion of broad JCLs, which are among the beneficial uses. It is very reliable for us to perform quick deletions or movements of more than 150 JCLs, which proves to be very reliable and accurate. These represent some of the use cases where we employ it.

We have not used Java workloads for BMC AMI DevX because I am primarily a mainframe-based scheduler, and we do not work on Java-based users.

BMC AMI DevX has positively impacted our organization. Bulk updates on any possible workloads was one of the key factors that helped us save a lot of time. When it comes to small targeted end dates where we have to work extensively and process items through Endevor, which we used six years ago, the processing consumed a lot of CPU and took considerable time. However, with Workbench, we already have everything sorted out regarding when we are going to perform the implementation. Despite time constraints, we are still able to complete tasks on time with the estimated target and have yielded very good results. Our clients have greatly appreciated how we handle scheduled maintenance.

I can share some specific outcomes. Back in 2020, working with Endevor, processing JCL moves and maps in one batch used to take us around ten to fifteen minutes depending on CPU usage. During an extended quarter, when several application teams requested a migration, it became hectic for us as wait time increased. However, with the DevX app, we were able to perform bulk updates rather than one by one, eventually completing the work within thirty minutes, which typically took two to three hours. This proved very helpful and efficient. The same applies to deletion of production sources, which was very efficient rather than taking extensive time to search each component individually.

BMC AMI DevX definitely helps me develop COBOL while juggling other responsibilities.

The prior technology that we used was Broadcom's Endevor tool, which operated linearly and required us to do everything manually in the CLI. This sometimes placed a lot of strain when we submitted each migration. However, here we can perform many tasks simultaneously, saving a lot of time and troubleshooting easily by getting help from AI, which serves a bigger purpose compared to what Endevor does. I can quantify it as being ten times better than the prior tool, making this a much nicer and more polished version.

The best features that BMC AMI DevX offers are bulk updates on JCLs and bulk moves of maps to a specific dataset without any errors and without any conflicts. People who know how to use it have always been very happy about how detailed and self-explanatory it is. When it comes to other moves involving modern IDE and AI assistance, we have Workbench, VS Code, and Eclipse. We also had streamlined onboarding that was very helpful for AI code translations. Additionally, for the code pipeline, we had extended modern CI/CD orchestration to the mainframe. Since it also supports Git compatibility, we integrated it for our use cases.

The Git compatibility that we use in the mainframe helps us with distributed Git workflows such as GitLab, Bitbucket, and Azure DevOps environments. Traditionally, mainframes rely on centralized Azure DevOps for source control management. This bridges that gap, allowing developers to check out COBOL and JCL codes, create isolated feature branches, and submit merge requests using standard Git commands while backend tools handle the mainframe build and deployment.

A major use case for us is that distributed teams work in their GitHub using Azure DevOps for branching and automated code reports. The mainframe team in traditional ZOS SCM uses green screen and Endevor. The most compelling part here is that this compatibility helped us integrate much more smoothly, and we had very good conversations with developers when trying to build something new and develop more use cases.

Regarding BMC AMI DevX's AI capabilities, while we have not worked extensively with them, the security concerns we have find it easier and very reliable since inactivity requires us to log in every time and other security measures are in place when uploading external vectors. That is where we excel. From whatever we have worked on, I have not experienced enough to elaborate further.

When it comes to BMC AMI DevX's AI capabilities, I feel that most of the integration process looks very convincing and smooth. From the developers' point of view, addressing skill gaps by making legacy mainframe code instantly understandable to modern developers is quite easy, and anybody can easily navigate through it. That is a big positive indicator for usage. Developers can highlight unfamiliar and undocumented COBOL or assembler code, right-click, and instantly generate a clear plain language explanation of the program's logic and behavior. This is very valuable, and the inline documentation can be copied and inserted directly into the source code as an inline comment, creating permanent documentation for future developers, which is a very important detail that we needed. These are some of the impressive aspects.

We had some hurdles with the hybrid CI/CD integration due to strict security aspects, but we managed to overcome it, and everything worked well when it comes to the integration part.

When it comes to understanding unfamiliar code, BMC AMI DevX leverages GenAI intelligent code analysis to accelerate and eliminate the friction of reading. An example is that developers can select a code sequence processing a single line of COBOL or assembler to request an immediate summary of its business logic. Instead of just explaining the syntax, the GenAI explains what the code does functionally. For instance, it calculates interest for active accounts meeting specific daily balances and writes to the daily audit file. Developers can instantly copy the AI-generated explanation and paste it back into the source program as a standard inline comment. This preserves the domain knowledge for future team members without needing manual definitions, which is very useful.

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.

I have been using BMC AMI DevX for the past four to five years.

We have not faced any major issues with the reliability of BMC AMI DevX.

BMC AMI DevX's scalability has met our needs as our organization has grown three times larger. Despite having a bunch of job scripts we had to reduce, we were still able to close that issue with BMC AMI DevX.

We had to reach out to customer support for BMC AMI DevX, and they were quite prompt and quick, which helped a lot.

I would rate the customer support a nine.

We were using Endevor, and since we had a lot of feedback and advice in completing tasks on time, we had to look for options. After checking with BMC AMI DevX providers, we found a lot of convincing features in the GUI, which felt user-friendly, so we decided to give it a try, and everybody was impressed with the output.

After moving to BMC AMI DevX, the number of associates handling the same workload for migrations got reduced from about twelve people to approximately four. We have reduced it by nearly three times, saving a lot more on budgets and creating margin for our company. However, I am not sure about the exact metrics regarding how much it was reduced.

Pricing, setup cost, and licensing were completely handled by our enterprise team, so I am not sure how it was done or arranged.

BMC AMI DevX was my first choice. We had other options, but I was not present during the decision point, so I am not certain about which other companies might have been in consideration.

BMC AMI DevX is deployed on-premises in our organization. Now that they are moving it to cloud, the migration is in progress.

We have not used the DORA metrics tracking for the decision-making process; we have not engaged with that.

I would advise others looking to use BMC AMI DevX that it is a very go-to product unless you are uncomfortable with a sophisticated GUI. It is really worth giving it a try, and there are many learning aspects in the tool which can be used for a lot of complicated migrations starting in various different fields.

I give BMC AMI DevX an overall rating of eight out of ten.

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.

Our primary use case is managing and deploying code. We also build outputs from the code. 

I think the most valuable features are code management, code deployment, and code generation. The fact that those three features are included makes BMC Compuware ISPW a robust product. If one of those features was missing, it would be less robust and less interesting. But because it has those three features, it is a very good solution for code development and management.

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.

I have been using BMC Compuware ISPW for about 10 years.

I would rate the stability of this solution a nine, on a scale from one to 10, with one being the worst and 10 being the best.

I would rate the scalability of this solution a nine, on a scale from one to 10, with one being the worst and 10 being the best.

I would rate their technical support a nine, on a scale from one to 10, with one being the worst and 10 being the best.

Positive

I would rate the initial setup of this solution an eight, on a scale from one to 10, with one being the worst and 10 being the best. The deployment took a couple of months.

The solution requires an intensive planning process to deployment. Also, deployment is not immediate. We're not talking about the deployment of an app like Windows, which can be done in five minutes. We're talking about months. In some cases, it can even take a year. With this solution, deployment is an ongoing process; it is not something that you do once and you are done with it. 

To deploy this solution correctly, you first need to carry out an analysis of the current situation. After that, you need to decide what to do with it. This product is, generally speaking, for organizations that have problems in the development cycle. This tool automates the development cycle and makes it more efficient.

After the solution is deployed, it can be maintained by a single person.

I would say I can definitely see the return on investment. Any product that provides efficiency has a return on investment. It secures one of the most important assets any organization has, which its development in which billions of dollars are invested. That is a return in itself. It also makes the development cycle much more efficient; by as much as 20% or 30%.

I'm a consultant who helps users determine which product they want. I am not a user. I help users evaluate solutions for the implementation of a configuration management tool.

I work for a huge bank, we use this solution for applications for grants, loans, and other stuff for our bank. DB2 is great. It is very robust with a great capacity to deliver the applications.

For bank applications, it's the best on the market. A lot of the major banks in my country use it. 

I have worked with DB2's great features in the last five years. The IDAA feature transformed the vision of warehousing, business analytics, and big data at my bank. Besides the mainframe, I saw that this solution was evolutionary. It gives real-time information.  

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. 

The stability is very good. 

The scalability is very good. They have a great success rate for the capacity of the application and scalability. I don't know of another database with this capacity.

We have had a few problems with support so I would rate them a nine out of ten. 

They didn't give us the answers we needed for our problems. We would try to explain the problem and they would give us a simple answer that didn't help. They didn't understand that our question was deeper than what they thought. I would have to schedule more meetings with them in order to actually get the problems resolved. Their techs need to be more experienced. 

The initial setup was straightforward. The time it takes to deploy a solution depends on the architecture. For a normal application for ZOS, starting from the development environment and pre-production, it should take around one week. 

We have a web feed and JPBC inside ZOS. It takes longer for this, around two weeks. There are more inquiries and more analysis required. 

I've had a great experience with BMC, but when a new feature or a new version would be announced, I felt that BMC was late to implement. 

I would rate DB2 a nine out of ten. 

We use it to update data in Compuware File-AID for IMS and File-AID MBF.

We also use it in test cases.

Compuware File-AID can be used for DB2 as well.

I like that Compuware File-AID can actually map out control sections within load modules, or, as they're now known, program objects.

It can run a batch job to produce reports and spreadsheets or CSB to format a spreadsheet.

I like the ability that it has to format copy books in a presentable manner. So, you will be able to see the starting offset in length of each field within the layout.

The use of the product is very straightforward as well.

Integration is very easy.

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

I've been using it for, probably, close to 30 years.

It is a stable solution.

We're a very small organization as far as mainframe development. There are only four developers who use File-AID. So, it's still getting ramped up as far as its usage goes.

Technical support is provided by a mainframe management company and is decent. Their response time seems pretty decent. It's gotten better over the years. There have been features or bugs that we've reported that didn't get resolved for several weeks, if not months, but that has improved. So, I would give them a nine out of ten.

The installation is pretty straightforward.

I think it's a very decent product and would recommend Compuware File-AID. I would give it a rating of nine on a scale from one to ten.