Exit programs allow you to customize software when the vendor has defined exit points for it. They are a great way to customize security and general function of certain applications. The registration facility built into OS/400 brings another level of "openness" to the AS/400-iSeries. It is a central place -- with standard interfaces -- in which IBM and other vendors can store exit points, and where users can specify exit programs for...
those exit points.
How to use the registration facility
As mentioned in part I of this article, the PCSACC "exit point", for example, is not part of the registration facility, although it is tied to it. The PCSACC network attribute has been around for some time while the registration facility is new. The registration facility's purpose is to centralize and standardize the various exit points available on the system. Instead of having a couple of network attributes here and a system value there, the registration facility provides a single utility to define and manage exit points and exit programs.
Many of the IBM-supplied exit points are new, and therefore do not have pre-existing counterparts such as the PCSACC network attribute. In those cases, you can work directly with the exit points using the commands and APIs listed in the section below Registration facility commands and APIs. To use the registration facility's Client Access exit points instead of the PCSACC network attribute, first change the PCSACC network attribute to *REGFAC. This will direct all Client Access requests through the registration facility and then you can work directly with the CA exits points in the registration facility. Use the following command to change your network attributes:
Now you can use the Add Exit Program command (ADDEXITPGM) to attach an exit program to, for example, the remote SQL function so that when a remote SQL request is made, the specified exit program (in this case, UCG/SQLEXITPGM) is called.
ADDEXITPGM EXITPNT(QIBM_QRQ_SQL) FORMAT(RSQL0100) PGMNBR(*HIGH) PGM(UCG/SQLEXITPGM)
Many exit points allow more than one exit program to be attached to them. The exit programs are called in order from low program number to high program number. The program number is specified on the PGMNBR parameter on the ADDEXITPGM command. The special value *HIGH assigns the highest available number.
The below program is an example of an exit program. Written in CL, it simply checks if the user is requesting the invoke function of remote SQL and, if so, rejects the request by setting the return code to '0'. Otherwise the request is accepted. (Note, the invoke function, if allowed, lets remote SQL users run commands on your AS/400.)
/* PROGRAM NAME: SQLEXITPGM */ PGM PARM(&RTNCODE &PARMS) DCL VAR(&RTNCODE) TYPE(*CHAR) LEN(1) DCL VAR(&PARMS) TYPE(*CHAR) LEN(5200) /* Check for Remote SQL Invoke function. The + function ID is in positions 21-30 of the &PARMS + parameter (RMTCALL = Invoke). + */ IF COND(%SST(&PARMS 21 10) = 'RMTCALL') + THEN(CHGVAR VAR(&RTNCODE) VALUE('0')) ELSE CMD(CHGVAR VAR(&RTNCODE) VALUE('1')) RETURN
Registration facility commands and APIs
The registration facility is really just a repository for exit points and their associated exit programs. It gives users the ability to store and retrieve exit point and exit program information, but the actual calling of exit programs is done by the applications that "define" the exit point. Here are the commands and APIs that make up the interface to the registration facility:
Work with Registration Information (WRKREGINF) command. This command show you all the exit points that are available on your system. From the main screen you can choose option 8 to work with exit programs (add and remove them) for a particular exit point.
Add Exit Program (ADDEXITPGM) command. Adds an exit program to a single exit point. ADDEXITPGM can also be used to create an exit point, but the exit is not usable until it is registered using the Register Exit Point API.
Remove Exit Program (RMVEXITPGM) command. Removes one or more exit programs from a single exit point. Can be used to remove all exit programs from an exit point.
Add Exit Program (QUSADDEP, QusAddExitProgram) API. API version of ADDEXITPGM command.
Deregister Exit Point (QUSDRGPT, QusDeregisterExitPoint) API. Deletes an exit point and all associated exit programs (the program objects themselves are not deleted).
Register Exit Point (QUSRGPT, QusRegisterExitPoint) API. Creates and registers an exit point with the registration facility. Also used to register unregistered exit points add by the Add Exit Program API and/or command.
Remove Exit Program (QUSRMVEP, QusRemoveExitProgram) API. API version of RMVEXITPGM command.
Retrieve Exit Information (QUSRTVEI, QusRetrieveExitInformation) API. Mainly intended for the use of applications that "define" exit points, this API returns information about one or more exit programs for an exit point so that the exit programs may be called.
- Unlike many other major components of OS/400, the registration facility lacks a manual of its own. Instead, documentation on it is scattered among many manuals and, in most cases, is inadequate. For example, it is just short of impossible to figure out what a particular IBM-supplied exit point is for and when it is called.
- IBM needs to supply more exit points. True, one of the major advantages of the registration facility is to provide independent software vendors with a central facility in which to register exit points and in turn provide users with one common interface in which to register (i.e., add) exit programs, but IBM needs to take more of the lead and register a few more of its own.
- I have run across a number of IBM-supplied exit points described in manuals only to find that they do not exist in the registration facility, evidently leaving the process of registering them up to the user.
- Most of the IBM-supplied exit points do not give their respective exit programs the ability to modify incoming parameters. For example, as with many IBM-supplied exit points, the data queue exit point is provided primarily for security purposes; its main function is to give an exit program the ability to either accept or reject an incoming data queue request from a PC. If rejected, a cryptic "function rejected" message is sent to the PC. It would be nice to send a user-defined message or, maybe, to accept the request but redirect it to another data queue by changing the data queue name in the incoming parameters.
Other IBM-supplied exit points
There are many other IBM-supplied exit points available, and not all of them are security related. The Client Access exit points were the focus in this two-part article because of the performance improvement it may represent to many of you.
About the author: Ron Turull is editor of Inside Version 5. He has more than 20 years' experience programming for and managing AS/400-iSeries systems.