Exit Strategies: Why Not Use the Best?
Exits are used often in software products to provide flexibility. They give you a way to hook into the processing at strategic points to deliver more value. As a product manager, I use exit strategies to look for places we can add exits to provide additional capabilities and allow users to better leverage what we provide.
But all exits are not created equal. The typical implementation on the mainframe is to have the code call an Assembler module. Normally, nothing happens—it’s basically empty. But it gives you a way to take the data that is passed, manipulate it and return what you need. You code it, assemble it, link it, and if you did it right you have the customization you need. But there are better exit strategies to do this.
Let me give you an example. Here at Compuware we converted from CA Endevor to ISPW for our Source Code Management (SCM). I noticed right away that ISPW used a superior way to implement exits. You simply go to a panel and select the exit you need to modify from a list of all available exits. This is important because there is no hunting around to find exit strategies—they are all listed.
Once you have selected the exit, you are taken to another panel that shows for that exit what you can modify. You can start by entering the routine you’ve coded, most often in REXX. You have a choice to invoke it either Pre or Post Operation. You can also select the specific environment where you want it to apply. So it’s not just one choice for the exit you need to code; with ISPW you can easily select multiple ways to handle one exit point. There are 37 different exit points you can modify and for each you can enter your routines—all panel driven.
With Endevor it’s a different story—a long one. You can only derive the process after looking through a lengthy manual. You write the exit in Assembler or COBOL, follow the naming convention, then include it in the exits table and update that. To debug your exit, there is a special trace facility. If you have a problem with your exit, you need to set up the trace facility and read the log where it shows Control Blocks and the registers with their values. Exit strategies are a tedious process.
Exits are a necessary part of software to provide for customization. There are differences and they have a large impact on the initial setup and especially for ongoing maintenance. I recommend taking a close look to see how your exits are handled.
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?
- Compile Skeletons: 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)
- Historical Re-enacting with the Mainframe Green Screen - May 29, 2018
- Why the Waterfall Development Methodology Has a Very Apt Name - April 17, 2018
- Mainframe and Distributed: Uniting an IT House Divided - February 13, 2018