Skip to main content

Overcoming Exit Routine Difficulties

The flexibility of z/OS means industry interoperability, but with it comes application programming risks.

Isometric illustration demonstrating stop signals and obstacles.

Since its inception in 1964, IBM’s flagship IBM Z* OS, today known as z/OS*, has been a general-purpose system, efficiently managing large-scale computing resources for virtually every kind of enterprise. Whether in commerce, medicine, science, military or other use, the same z/OS code runs the applications that run the world’s largest businesses and governments. Yet every business is different. The data processing needs of a hospital are clearly not the same as those of a grocery store chain. So, how is it possible for the same OS to meet such differing requirements?

Flexibility Is Key

The answer lies in z/OS flexibility. While the base code is the same for every installation, the OS is highly customizable. The SYS1.PARMLIB data set alone can include more than 85 different members, each of which may have anywhere from a few to dozens of parameters specified. Virtually every subsystem in z/OS, from DFSMShsm to JES2 to TSO to IPCS also has its own “customization” manuals, associated control data sets and parameters.

Exit Routines Provide Flexibility, However …

  • Another less well-known but far more powerful method of providing the flexibility vital to z/OS is its support of exit routines. In both z/OS itself and in its subsystems, well-defined program exit points exist at which an external routine, or exit routine, can gain control. Because exit routines are programs, they can provide customization and additional function far beyond what’s possible with simple PARMLIB members and control statements. Exit routines are so useful and flexible that virtually every installation relies on at least a few so programmers can add tweaks. Exit routines can be used for purposes such as:
  • Allowing, preventing or even changing FTP commands and parameters on the fly
  • Managing JES job attributes, such as destination, timeouts, region size, print lines and so on
  • Formatting batch “flowerbox” output and statistics
  • Controlling logon processing, use of “firecall” user IDs or to manage passwords and
  • passphrases
  • Managing JES attributes for jobs, such as destination and resource use
  • Controlling SMF record writing, switching and dumping

Because of the flexibility available in program logic, exit routines can be tailored to the exact sort of processing an installation needs. Exit routines can perform tasks such as reading data sets and performing table lookups on external data, calling RACF* or other security systems to check on authorizations, sending emails, checking the time of day or indeed any other function that any program can perform. This gives exit routines enormous power. Virtually every z/OS installation depends upon some exit routines, whether in z/OS itself or in JES, TSO, DFSMShsm or other subsystems.

What’s the Risk? 

Exit routines have all of the advantages of functioning like programs, but they also have some of the drawbacks. While the z/OS and subsystem exit points are well defined and the parameter lists and return codes are well documented, there’s no guarantee that the parameters and values for the exit point will not change between one z/OS release and another. So even if there’s no change in the logic, the exit routine must at least be recompiled for every release.

This brings up a second drawback. While programs (such as exit routines) are infinitely variable in the number and type of tasks they can perform, once written, they’re difficult to change. Any change in the logic of the program requires updating the source code and again, recompiling. And, of course, any time a program is changed, it should be thoroughly tested to ensure the change doesn’t introduce any problems.

There are also some unique and important challenges to exit routines for z/OS and its subsystems. Some exits are supported by the dynamic exits facility introduced by IBM many years ago. Dynamic exits are somewhat easier to manage, because they can be enabled, disabled and updated by command, and multiple exit routines can be associated with an exit point. Unfortunately, not all exit routines can use the dynamic exits facility. In fact, most cannot, and activating, deactivating or changing non dynamic exits routines can be challenging.

Experts Needed

In general, exit routines in z/OS systems must be written in
re-entrant Assembler language, which requires skills that are nowadays increasingly scarce. Furthermore, many of the most important exits must be written to run in a privileged status—often in supervisor state and system key. This makes testing still more difficult and extremely important. An error in a privileged environment can result in a security exposure at the least or a catastrophic failure at worst. Testing privileged routines, however, can require expertise that your organization may have to outsource, meaning unplanned expense.

The difficulties with exit routines arise not with the exits themselves, which are a powerful way to provide detailed, granular processing that can be very useful. Instead, what often keeps installations from taking advantage of the flexibility and functionality of exits is a lack of knowledge in them, which is needed to build, maintain and test critical, reliable, Assembler-language routines.

Overcoming Exit Routine Difficulties

Exit routines can provide valuable functions, accessing data and performing tasks that ordinary parameter members can’t provide to z/OS or its subsystems. So it’s worth considering what can be done to overcome some of the difficulties described above. While Assembler language skills are in short supply, some installations may be able to leverage programmers’ C* language experience with IBM’s Metal C compiler to generate Assembler-source output. 

For exits that are supported by the dynamic exits facility, exit routines can be written and tested independently of existing exits by specifying the jobname on SETPROG EXIT commands. For exits that cannot take advantage of the dynamic exits facility, testing can often be done on a separate “sandbox” LPAR. And, of course, vendor products are available that address these issues. 

Sample Exits from IBM

Every z/OS installation has a “wish list” of items that would be nice to have to make the installation smooth. Sometimes, the functions needed for those items are already in your shop—all you need is a system exit. Each of IBM’s “Installation and Customization” manuals that describe exit points include sample exit routine uses. A look at these sample suggestions can trigger some ideas. 

IBM Systems Webinar Icon

View upcoming and on-demand (IBM Z, IBM i, AIX, Power Systems) webinars.
Register now →