Carol explains the concept of exit programs and provides examples of how they can be used to customize your IBM i administration.

The terms “exit point” and “exit program” are often used but are rarely explained. New exit points are added to most IBM i releases, so I thought it might be helpful to explain exit points and provide some examples of how you might use them in your organization.

Exit Points That Allow Control

Let me explain the concept of an exit point using the ones you hear about most: the exit points associated with network access—FTP, ODBC, etc. An exit program is a point in a process where IBM has defined that a user-written program (an exit program) can be called. So, for example, a user attempts to FTP a file to their PC. Before the transfer occurs, the operating system examines the FTP server exit points (QIBM_QTMF*) to see if a user-written program has been assigned. If it has, that exit program will be called before the file is transferred to the workstation.

When an exit program ends, the operating system resumes control of the process. In the case of the network exit points, the exit point has been defined so that it can signal back to the operating system that the transaction shouldn’t continue. To facilitate the decision of whether the process should continue, the operating system passes the exit program information, such as the profile making the request, the file being accessed, the IP address from which the request is coming, and more. Vendors, such as my employer HelpSystems, have taken advantage of these exit programs to provide products that allow you to control user access to application data from “outside” of the application menu—for example, prevent all users except administrators from being able to FTP to or from the system, stop application users from performing actions such as uploading files or downloading files containing confidential information, or allow DDM connections from only a specific IP address.

I have written before about implementing multiple layers of defense, and these network exit points can be used as one of those additional layers.

Once object-level security has been implemented, exit points can provide “situational” control. For example, a user in finance may need to be able to download monthly accounting data into a spreadsheet. This requires that the user have *USE authority to the file containing the data. But *USE will also allow the person to FTP the file off the system. With exit points, you can allow the user to download via ODBC but prevent all other network access.

What the exit program does with the information passed to it is totally up to the exit program. It can use all of the information, use some of it, or ignore all of the information it’s passed. In addition, it can decide whether or not to signal back to the operating system whether to continue or not. For example, you may not be interested in controlling network access, so the program may simply log the information passed and always indicate back to the operating system to continue processing the transaction.

Other exits that allow you to take actions when they’re called are the IFS Scan exits. They were originally provided so that vendors could develop real-time virus scanners. The exit point is defined to allow the exit program to take action against the file—either before or after the file is written into the directory. But again, the exit program determines the action to take. So while it can be used in the traditional sense of scanning a file before it’s written to disk, you could also write an exit program to change the ownership of a streamfile after it’s written to disk, for example.

Exit Points That Are for Information Only

Exit points are not always defined to allow the exit program to indicate the process should stop. The user profile exits are one example. IBM has defined exit points that are called when a profile is created, deleted, or restored. The exit program cannot indicate that the profile shouldn’t be deleted, for example. Instead, the exit program is passed the name of the profile being deleted, and then it's up to the program what it does with the information. For example, if the program is called prior to the profile being deleted, the program can “un-enroll” the profile from applications where the profile is required to exist for the profile to be removed. But if the program is called after the profile is deleted, it can delete user libraries that are owned by the user’s group or perform other clean-up or maintenance activities.

Where Are Exit Points Defined?

Most exit points are defined in a repository called the Registration Facility (WRKREGINF). However, some of the original exit points are still defined in system values and network attributes. But even those now usually point to a new exit point that’s been defined in the Registration Facility. An example of this is the QPWDVLDPGM (Password Validation Program) system value. Today, you can specify the value *REGFAC, which means that a program registered at the QIBM_QSY_VLD_PASSWRD exit point will be called when a user changes their password via the Change Password (CHGPWD) command or QSYCHGPW API. One example of an exit that isn’t defined in the Registration Facility is the FIELDPROC feature added in V7R1 to enable column-level encryption. The FIELDPROC feature is an exit whose assigned program is called when a field is written to or read from. In this case, the program is assigned via the FIELDPROC clause on a CREATE TABLE or ALTER TABLE statement.

Other Information About Exit Points

Numerous exit points have been defined that are not security related. For example, several work management-related exit points have been defined. There’s an exit point defined to be called prior to powering down the system. Command exits have been defined and are often used to examine the parameters specified to allow/disallow certain parameters or to run the command with only allowed values or to run a version of the command in a specific library. Another interesting fact is that most exit points allow multiple programs to be defined. For example, multiple programs can be defined for the QIBM_QSY_VLD_PASSWRD exit point. All programs registered against this exit point will be called unless one of them returns with an indication that the password can’t be used.

Summary

Exit points are a way that IBM provides us with the ability to customize processes or provide additional control over a process. Life without exit points would make administering the system far more hands-on, eliminating the ability to automate processes and eliminating add-on features that vendors provide. For information on the exit program definitions, go to the IBM Information center > Programming > APIs > API Finder. Go to Find by Group and click on All Exit Programs:

https://www.ibm.com/support/knowledgecenter/ssw_ibm_i_73/apifinder/apifinder80.htm?lang=en.

This provides you with the list of exit programs that are also APIs. While staying in the Information Center, you’ll also want to use the search terms of “exit program” and “exit point” to see a more complete set of documentation. To see the programs registered against the exit points, type WRKREGINF or, for a printout, WRKREGINF OUTPUT(*PRINT.)