Does our CICS NEWCOPYs and Db2 binds, reducing operations and DBA workloads
What is our primary use case?
We use it for change management and source control.
Pros and Cons
"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 of the operations folks and off 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... ISPW is constantly aware of it. It notifies when someone else is using or has a different version of that component."
"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."
"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."
What other advice do I have?
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…