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. 

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. 

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.

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.

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

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.

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. 

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.

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.