Compile Skeletons: Why Not Use the Best?
As a Product Manager I’m constantly looking for the win-win option of something that provides flexibility with minimal complexity. Often this balance is only achieved by starting with the right philosophy and continually learning from customer experience.
Let me give you an example of what I mean. Here at Compuware, we converted from CA Endevor to ISPW for our Source Code Management (SCM). When we did that we found some stark differences between the tools.
ISPW uses a cleaner, easier method of compile skeletons to handle the JCL. These are standard ISPF skeletons using simple substitution, nesting and conditional pathing. They are modular and reused. You have one skeleton to handle a COBOL compile, substituting the COBOL version library, while other skeletons handle a DB2 bind, link edit and so on. With a few simple compile skeletons you can cover the wide range of compiles, and because of the substitution, they rarely need to be changed.
With Endevor you have to code your own processors to do pretty much anything—you’re forced to actually code the important parts within the framework. This carries into the Compile or Generate processes, where there’s an even more complex method hidden in the Generate processors. Something similar to a skeleton is used in each processor, so instead of having one COBOL compile skeleton, you have to copy it and use it in multiple processors. This duplication adds to complexity, makes any change painful and leads to a lack of standardization.
How We Reduced Our Processors with ISPW Compile Skeletons
At Compuware, we experienced a major increase in development efficiency when we converted to ISPW. We felt so strongly about what it had done for our organization that we decided to acquire its assets. It’s been integrated with Topaz Workbench, providing users access to a host of developer productivity tools.
With ISPW, we found that the Endevor Generate processors for Copy or Include Types could be discarded because ISPW doesn’t need skeletons to manage them. Instead, all syslibs and maclibs are handled by a simple skeleton table Include statement, which is sensitive to the concatenation requirements—one line of code to dynamically handle all the maclibs.
In the end, all of our Generate processors, over one hundred, were reduced down to six flags on the ISPW Generate options screen and about 20 ISPW skeletons. Now when an update needs to be made it is quick and easy.
I recommend you always look to get the win-win that your users need. As we learned, architecture decisions matter for the end user experience, and with ISPW you can have the flexibility you need without having to be overly complex.
Read my other posts in the “Why Not Use the Best?” blog series
- Data Access: Why Not Use the Best?
- Balancing Complexity and Flexibility: Why Not Use the Best?
- Exit Strategies: Why Not Use the Best?
- Impact Analysis: Why Not Use the Best?
- Waterfall to Agile SCM Conversion: Why Not Use the Best?
Latest posts by Mark Schettenhelm (see all)
- Why the Waterfall Development Methodology Has a Very Apt Name - April 17, 2018
- Mainframe and Distributed: Uniting an IT House Divided - February 13, 2018
- Waterfall to Agile SCM Conversion: Why Not Use the Best? - February 6, 2018