Sr Consultant Project Manager with 10,001+ employees
Consultant
2022-01-04T19:36:00Z
Jan 4, 2022
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.
Works at a insurance company with 1,001-5,000 employees
Real User
2019-07-10T16:31:00Z
Jul 10, 2019
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.
Support for Development Teams on Mainframe at CNP TI
Real User
2018-09-14T08:14:00Z
Sep 14, 2018
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).
A modern, end-to-end Agile source code management, release automation and deployment automation tool that enables mainframe application developers at all skill levels to fulfill business requirements, optimize code quality, and improve developer productivity through mainframe DevOps. With ISPW, developers can:
Easily perform concurrent development to support Agile Development practices
Leverage Jenkins plugins to manage code throughout the lifecycle
Use REST APIs to automatically connect...
Our primary use case is managing and deploying code. We also build outputs from the code.
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.
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.
We use it for change management and source control.
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).