BMC AMI DevX Reviews

We are using the Topaz Workbench to replace file access, browsing, and editing  activities currently done in ISPF.  Also using XPEDITER in Topaz to debug programs.

The smart editor helps because it includes code completion technology, cutting down keyboard strokes. The flexibility of having a window longer than the ISPF max lines on a screen allows more lines to be viewed to get a better view of the code without the need to print it.

I've talked to some people who use it for applications and they are seeing that with the combination of our source management plugin and using the SlickEdit editor in Topaz, as well as being able to have the Host Explorer, is an improvement over ISPF. They have been able to see a savings of one day a week.

We can develop in parallel today on ISPF, but it is giving us the advantage of the newer interface into the mainframe programming languages that younger programmers can use and are familiar with, rather than using the ISPF green screen. Our intention is to use Topaz for the next generation of mainframe developers to maintain mainframe applications. As we hire new people, if they're familiar with an Eclipse environment, which Topaz is included, we can get people to become productive faster, because all they have to learn is the language. They don't have to learn how to manipulate through a green screen.

Another advantage of using Topaz is for IT personnel that are not familiar with the mainframe to now have an interface into our z/OS environment with an environment similar to the Windows Explorer interface instead of using TSO/ISPF.

I have also found that XPEDITER under Topaz is easier to use than the old green screen.  It is easy to save breakpoints in Topaz and reuse the test in Topaz than from a green screen in either CICS, or ISPF.

I really like the enhancements that have been coming from Compuware.  They listen to the ideas from their customers on how to improve the product.

One of the features that I like is that I can open up and move tabs outside the eclipse window to different screens in a multi-screen environment, and I'm able to expand it to see a larger amount of code than I could see on an ISPF screen.

I also like the hyper links for datasets when looking at JCL that can be used to look at contents of files.

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.

More than five years.

It's very stable. We haven't had any issues. The biggest hiccup is that Topaz doesn't always play well with the IBM products that we have integrated in our Eclipse environment we have built, when installing it. The person who's doing it has to basically rebuild the Eclipse environment when he puts maintenance on to Topaz. 

Scalability is not a problem. I've been doing some testing with files that I have access. I can scale it, bring up all my datasets that I need to look at. It works just fine. I can add new filters, whatever I need.

With how we have configured Eclipse, it takes a couple of minutes to initialize, but once it is up, the performance is very good.

When I have had to contact customer support they have been very helpful at resolving the issues. 

We've just been using ISPF. The decision to bring Workbench to our organization came about because we had the Compuware products, File-Aid and Xpediter, and they provided a free version of Topaz that includes Host Explorer, Slick-Edit and the interfaces to our Compuware products we currently license.  A colleague that is familiar with other products commented that Topaz is one of the best products he has seen.

The initial setup is very simple.  Again, since we are combining multiple products from different vendors, we have to be careful about the version of Eclipse and the order we install the product into eclipse.  Sometimes this takes a few tries to get it right.

For deployment, zip up the eclipse program files and a default workspace.  These files are sent to our desktop management group who deploy the software using Big Fix.

We also recommend that the developers back up their workspace to a network drive on a regular basis so that they can recover if there workspace gets or they make a change and want to back it out.

We did it all in-house.

It depends on what the programmer is doing. It might save them one to two hours in a week, and as much as one day per week. It depends on how much programming they're doing, and what they are doing in their day.

We are using the free version, so if Compuware products are used at your company, the base version of Topaz as well as the products licensed are available.

We've looked at some competitors. The only potential competitor might be IBM, with their IDz product. It has an integrated compiler with it. Topaz does not.

Look at it very closely. If you don't have anything, Topaz is great to start with, especially if you're a Compuware shop, since it is free for Compuware clients.

I've been using it more often because we added an Eclipse plug-in for our source management system.   Now, we can start really taking advantage of the Eclipse environment for  our mainframe development.

We don't have an automated testing solution, at least for unit testing. Any automated testing that's done is done more at the user-acceptance or QA-testing stages. That's been done mostly with Rational Functional Tester. We are probably going to be looking at an automated process within the next year or two. We will consider looking at the Total Test product from Compuware, since it plugs right in.

We have built a single Eclipse environment for all products. We use the P2 installs for the products, including Topaz, and put them into a single Eclipse instance that has a combination of IBM products, our source management product, and other products. We try to have a single Eclipse instance to handle all the application development needs for mainframe developers.

As for providing intelligent insights into programs and data, we haven't used the Topaz piece for that very much. We've got an IBM product, Application Discovery, to give people a little more insight into their programs and their systems. And that's another Eclipse product, so it is included in the Eclipse environment. We've basically chosen to go a hybrid route with products that we already have.

We have 30 or 40 people using it on and off. A lot of them are application programmers. It requires less than one FTE for deployment and maintenance. It's pretty simple to maintain.

I expect our usage to increase. There are going to be some people who won't use because they don't want the learning curve and are very adept at maneuvering around ISPF.  The eclipse environment is going to be very beneficial as we replace retiring developers with younger developers that are familiar with Eclipse.

I would rate it an eight out of ten. It is a great tool. There are just a few things that you have to get used to. 

We use it for change management and source control.

It has provided us with a number of improvements. The biggest improvement is its deployment facility. It does our CICS NEWCOPYs and our Db2 binds for us, whereas before, that was a manual process. It takes a lot of the workload off the operations folks and the DBAs.

We had parallel development before, but the way ISPW implements it is better. It has more control and oversight of the process, whereas before, it was like the Wild West. Everybody could have their own package with their own version of the component in it, and they had to do what ChangeMan called an audit before they could promote it. ISPW is constantly aware of it. It notifies when someone else is using or has a different version of that component. It protects the source better than ChangeMan did.

It's also starting to help our organization realize the benefits of DevOps. We're fairly new, and we still haven't had the Topaz training yet, where a lot of that stuff will be more apparent. We'll be able to use the GUI tools.

It helps us develop COBOL while juggling other responsibilities. This is less time consuming than using the old product

We have seen an improvement in the rate and level of quality at which we deploy changes. I don't know if I could give you an accurate percentage. It's probably 100 percent. It's much better. 

It's pretty much a purpose-built application for source control and change management. That's what we use it for.

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.

Less than one year.

It's very stable.

It seems to be very scalable. There is considerably more scalability and functionality than we had with ChangeMan.

We haven't had to call support for this solution more than once. We do have lots of experience with Compuware. They're great. Compuware has good support.

We used Serena/Micro Focus ChangeMan for this functionality and we switched for cost and functionality reasons. There is a lot more functionality with ISPW and there is clearly a lot more effort in the continued development of ISPW. ChangeMan was somewhat languishing. They didn't really update it much.

The setup was pretty complex. Compuware came in and did it as part of the purchase, and then they did some training.

A lot of it was conversion from ChangeMan. That was something that we could not have done, just to state it simply. We don't often come across a product that we can't convert to and implement. We've done a large number of them. This one, in particular, after seeing what they had to do - we couldn't have done it.

It was a rushed deployment because we had a licensing misunderstanding with Serena/Micro Focus. We pretty much had to convert in a month. There were actually a couple weeks where we went without a change-control product, and we were doing manual compiles. It took a month to convert it and implement it, and then we were making changes and still implementing, to be honest. That propagation issue is one of them; the planned binds is another. There are still a couple things that are not implemented. But it's net new functionality that we never had before.

Because it was so rushed, our implementation strategy was "cross our fingers and hope for the best." We actually had a longer-duration plan, but when we found out from our purchasing department that our licensing was about to expire, we had to rush things. We're not a good example to use for the right implementation approach, because it was so hurried.

We used Compuware's ISPW conversion team. It was a company Compuware purchased and that is what they specialized in: change control product conversions. It was Compuware's unit up in Canada, and they were great to work with. They are experts in the subject material and easy to work with. Nice people.

I like the seat-based licensing much more than MSU-based licensing, and that the cost has been competitive.

We had plans to implement Endevor but in evaluating Compuware ISPW vs CA Endevor, there was never any traction from the change group. The people who admin-ed ChangeMan before we inherited it were not very technically savvy. We just didn't have any good resources. And to bring Serena in to help us upgrade ChangeMan or to bring CA in to convert ChangeMan to Endevor was very cost-prohibitive.

Take a longer implementation path than we did. Don't rush it. We were forced to rush it and we would incur a large cost from Serena. My advice is to plan longer and take more time to implement, which we had planned on doing. We were going to do a phased implementation. We just didn't have that luxury.

To anyone who is considering moving from an alternative solution to this one, I would say, "Don't hesitate." I've told everyone I've talked to that this is a much better product. They'll be much happier with it.

There was a lot of resistance early on but, the more people have used it, the more positive they have become. I think they have really started to like the product. We have about 50 users and all of them are in application development.

For deployment and maintenance, it was just me and one of my staff. We maintain the skeletons and CLISTs and troubleshoot if we have a promote/deploy failure. They do happen but probably less frequently than with ChangeMan.

It's used every day. It's constantly being used by the application developers. We don't have any explicit plans to increase its use, other than as we add developers. We do plan to make use of Topaz. We've been struggling with coming up with a training date but once that occurs, we hope that people that would use Topaz.

We don't have it integrated with anything. There's been some talk of looking into that but I can't say which direction it will go.

I would rate this solution a nine out of ten. The two things I mentioned earlier, the ways it could be improved, would make it a ten. If we could get a little better documentation and a little better error reporting from the promote/deploy processes, that would sure make my life easier.

Today, the mainframe is our foundation where our customer data lives. Interfacing with the mainframe is how our distributed systems provide services to our customers, regardless of the channel  used (Mobile, User Interface, etc).  Until an alternative cost-efficient technology is identified that has the processing power of the mainframe, our focus will remain on modernization.  Our focus is to utilize tools and technology that allow for more automation, real-time services, and communication with our distributed products in a way that reduces cost and increases efficiency.

With the use of ISPW, we were able to reduce our deployment time for specific applications  by utilizing the auto-deploy features. Using tools such as ISPW also increases our mainframe developer’s knowledge of Eclipse-based tools that the distributed products utilize. 

We’re also experimenting with being able to utilize distributed developers to see if they can utilize the  ISPW analysis tool to identify/make changes in COBOL without really knowing this technology.     

The visual ability to see potential downstream impacts to code changes is a value add in helping our developers identify and understand the impact associated with their change. Utilization of the deploy feature in ISPW has also been a key functionality.

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.   

Our use case is debugging using Xpediter.

The debugging is really the most important feature, enabling us to be able to step through.

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.

I think some of the issues we've had may have been the way it was installed. We did have some issues but it seems to be working now.

In terms of scalability, I really haven't dealt with it at that level. It's pretty much been one-for-one types of situations, either batch jobs calling one program or intercepting one program in CICS.

Compuware tech support seems to be okay. For the most part, if I have any issues I turn it over to someone here and then they get in touch with the vendor and then they have had me get on and do a shared session where they can watch what I'm doing. So they have been fairly reactive.

We were using Compuware Xpediter before, on the mainframe. I switched because we were told to switch. It was a management directive.

It wasn't complicated. They did come in and give training and it pretty much worked okay.

I really don't have any advice, I haven't used it enough.

The primary use is programming, database design, and development.

The most valuable feature of Topaz is Xpediter. It's more flexible than Xpediter through MVS.

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 constantly encounter stability issues. That might be related to how it's installed. We're going through VDI sessions. 

I have had no issues with scalability.

Tech support is fairly responsive. Some of the replies are, "Wait until the next release." And some of the replies are, "This feature, it will not be supported until further notice."

We switched to Topaz because our management deemed it was a tool that might benefit us in the future. Our mainframe programmer is retiring and leaving the company.

The setup is done through our tech support group, and we are then given the platform to run. The tech support group is not dedicated to Topaz and, while there is one contact within that group, they are stressed and the resources available for Topaz are not as complete as they could be or should be. So installation is hit or miss - whatever Compuware drops down and can help install and attach.

It might be of benefit if there were training for, and incorporation of, millennials and new people coming in to work on the mainframe through an Eclipse environment. But as far as people who are already familiar with the mainframe, this solution has some big drawbacks.

Our primary goal wasn't using Topaz Workbench. Our primary goal was to satisfy people in cyber security roles. We just included it because people were using the product a little bit here. What we did was rolled everything up, taking all the plugins from other third-party vendors into the Eclipse state, then put those in as plugins.

With our environment, we have taken the core clutch open source software and added a third-party vendor plugin into Eclipse. We use the Topaz Workbench, but not for any insights in the programs. The software that we have today is still a basic level mainframe software integration in the total Eclipse environment. We haven't taken advantage of any new features or tools which are out there for any Eclipse-based tools.

The byproduct of setting our Eclipse up for cybersecurity should allow newer developers to work, who are used to this type of environment.

It helps our staff work by speeding up their documentation process.

From a development point of view, we use it to log documentation and edit steps. The documentation is easy to read and our developers can add information into documents simultaneously.

We are also using the Topaz Workbench Host Communications Interface with its data sets. 

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.

Once we got the configurations and deployment rolled out, it was very stable. I haven't had any major issues with Eclipse or the Topaz Workbench plugins.

I don't know which vendor plugins didn't like the other vendor plugins. I needed to get to the bottom of it. However, we just started the next release of it, and the components seem to be a lot better this time.

I haven't had any scalability issues. As it is on the desktop, scalability is not relevant. 

The initial setup of Eclipse was straightforward. However, the problems were more complex because of all the third-party competing vendor products. So, getting it set up and installed was easy, but getting it rolled out was a bit difficult because of some of the configurations going to people's work spaces.

We didn't roll it out the way a normal Eclipse works. We rolled out select PT Plugins, then uninstalled and reinstalled. The last one we did, we had to rollout the binary and a new set of Eclipse Workspace because of some configuration issues. This made it more complex. I don't know if it was an issue because of Topaz Workbench or an issue between the third-party vendors plugins not working well together. So, I can't say if it was Topaz Workbench,

I do all the deployment and maintenance.

It has saved our developers time and effort when working on documentation, which is now more readable and fluent.

In general, Compuware tools are very competitive.

As far as features, I want it to have all the nice features, like the automative testing and all the different components, but we didn't pay for them. 

We are using a competitive product to obtain intelligent insights.

The Topaz Workbench is easy to use with good plugins. I would recommend people use it, but I would install it as a solution, not as a standalone. Get a single pane of glass for all your developers.

We don't have an automated unit testing solution. It's all manually based for the mainframe. Currently, we don't have an automated testing testing. We may look to adding this feature in the future. However, we have some challenges because we are still mainframe-centric, so the SCMs on the mainframe don't click well with other tools.

The solution should expand in the next couple of years as the company struggles to get developers to do COBOL.

The solution was rolled out through mainframe developers only. Topaz workbench is one of the most integrated into Eclipse that I've seen from the mainframe vendors. For example, some of the other vendors don't use the Eclipse functionalities.

The postings on this site are my own and do not represent in any way Western & Southern Financial Group's (including its member companies) positions, strategies or opinions. The information contained on this site is for informational purposes only and should not be considered as investment advice or as a recommendation of any particular strategy or investment product. This profile should not be considered as a solicitation for services.

It's an optional feature that our users are able to use for mainframe development and data analysis.

It has been an optional feature. It hasn't been very heavily used, so I don't really have a concrete example of how it has improved our organization. We are trying to ramp it up as we get more DevOps initiatives in the company.

• Modernized development portal
• Helps reduce the learning curve for younger people coming in to work on the platform

We haven't had any stability issues.

Again, it's had a low-utilization rate. We haven't really had any stress test of it.

They have good tech support.

I was not the primary one to install it. We do have to go through our corporate installation procedures, and that's probably more of a challenge than working with the install itself.

It was probably of moderate complexity. It installed a little bit differently than other mainframe products with its web servers and things like that. I don't really know how to rate it complexity-wise.

In terms of pricing, there isn't an extra charge for the parts of it we use. It comes with the licenses we purchased for other products, so no complaints there. The licensing is built in with the other products that you purchase from Compuware.

Although I haven't evaluated the IBM option or the CA option, those ones have extra licensing fees, unlike the Compuware solution.

Focus a lot on user training, anything you can do to enhance the user learning and utilization of it. It is a switch from traditional mainframe tools, so it does take time to work on the training.

Overall, I give it a nine out of ten. It's pretty well implemented and documented. I know they are continuing to add features to it. Some of their products aren't up to full functionality, to what they have on the mainframe, but they are working on that. They are constantly adding new features.

Our developers use the tool for application development.

It's helping onboard application developers who might be new to the mainframe environment. Whether they're interns or global development resources, they might be new to the mainframe environment, and giving them this Eclipse tool to use, instead of having to learn the traditional mainframe interfaces, has helped them with that onboarding process.

The most important features are the file editing and browsing features. They are essential to an application developer; those are functions they have to be able to do. Having some nice features related to those activities really helps them. 

Also, the debugging capabilities are important. Again, they are essential to application developers.

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.

We have not encountered any stability issues so far. We've gone through two upgrades and we haven't had any issues with the upgrades. If anything, I'm having a hard time keeping up. They put out releases quarterly, and sometimes those quarterly releases have some really nice features, but the process for me to bring that software in, test it, and then roll it out to our end-users, makes it difficult for me to keep up with the rate at which they're putting out releases. But we haven't had any stability problems with it at all.

We did initially encounter some scalability issues. When we first started bringing it in at the end of 2016 and the beginning of 2017, its memory requirements were pretty substantial, and some of our developers - the machines that they were working on at the time - were running into memory issues. It would run very slowly or they would have to restart or it would hang. But since we've upgraded our developer machines, at end-of service - our routine process - and they've gotten additional memory on their machines, we haven't had that problem anymore.

As far as the software vendors that I work with go, Compuware has some of the best support, in terms of listening to customer requests and accepting enhancements to the product and the like. We haven't had many issues with Topaz Workbench where I had to open problem tickets. The problems that we discover in Topaz Workbench are usually attributed to some other product. But their support is some of the best that I deal with.

Topaz is the only Eclipse-based developer solution that we've had at UPS.

Initially, it was fairly complicated. Topaz leverages the functionality from other products quite a bit, and the setup issues were attributed to those other products: things that we didn't have in place, we didn't have installed, we didn't have configured. I spent a lot of time going through the features of Topaz that were not working, trying to find which product it was that was missing a configuration step or a setup step. That took me the better part of six to eight months to get it all ironed out.

It was fairly complicated to get all of the features and functions working. As far as Topaz itself goes, they're just built-in and expected to work, but as I said, those features are really attributed to other products, the setup and configuration that's required for those products. But since we've gone through those initial setups, doing upgrades and doing maintenance has been really straightforward. There has really not been a lot to do in the configuration and setup portions.

Topaz Workbench is included in our Enterprise Agreement. They've been great as far as letting us deploy it to as many users as we want.

The only thing I would mention related to the licensing and/or the pricing is that they have some visualization features in there that are licensed by concurrent users. We're starting to trip up on that. We're looking to probably increase the number of concurrent licenses that we have. But those types of licensing strategies, where they license by concurrent users or the number of seats, are confusing for some people. They don't understand why it works sometimes and doesn't work other times.

It would be much easier if it was licensed a little differently than that. To try and explain to my end-users why certain features don't work some of the time but other times they do, it's a little confusing, and it's because of that concurrent user license strategy.

We didn't evaluate other products before choosing this product. The product was included in an Enterprise Agreement. When it was included in our agreement, we were not shopping for an Eclipse-based product like this. When we did need one, it was the one that we had and I think we got lucky, because I have seen competitors' products and I think Topaz from Compuware is far above and beyond its competitors.

Pay attention to the installation of those back-end products. Topaz leverages the features and functions of a lot of mainframe-based products, so you really have to make sure that those other Compuware products are installed and that they're configured properly. You can spend a lot of time trying to research why features of Topaz are not working, and it turns out that it's really a feature of another product that you don't have installed or configured properly.

I rate it as an eight out of ten. The only reason I wouldn't rate it as a ten is because of those initial setup difficulties that we had and because the system requirements for the tool were, initially, pretty lofty. It's a pretty memory-extensive application to run on your workstation. But I think that's common to a lot of Eclipse-based products like this. I don't think it's necessarily a Topaz issue, it's more of an Eclipse issue. The lighter weight they can make it, the better it is for companies like us which have to push it out to hundreds of users, potentially.