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. 

We use it for change management and source control.

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.

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

In 2018, we executed a migration from an LCM product (ASG: Allen Software Group company) to an ISPW in order to manage our mainframe programs (mostly Cobol, few C, and ASM).

• We use ISPW for SCM and ALM, built and deployed from the development environment to the production environment on IBM z/OS.

• ISPW can be used on both Eclipse Neon 4.6.3 and ISPF panels.
  

• In our company, developers are using ISPW in Eclipse to have the benefit of an IDE and to use others plugins from Compuware Topaz solution or other providers we have.

• ISPW administrators and production teams use ISPW on both Eclipse and ISPF panels depending on the tasks they have to manage (a part of the administrative task is not available in Eclipse plugin).