TPFDF should have user exits for all the API commands

TPFUG_Req_Number: DF00178
Contact Originator Id: claudio.jorge@eds.com
Abstract: TPFDF should provide user exits for all of the application API commands such as the DBOPN (open), DBCRE (create), DBRED (read) and DBCLS (close) commands
Description: User exits should be provided in the DBDEF for use with these commands that open, create or delete a TPFDF sub-file. These user exits could be used for various initialization or house-keeping actions typically performed on a file. The open exit could be used for DBDEF over-rides e.g. overlaying the sw00sr with a different File Version (FVN) to support a database migration, or to modify certain options temporarily (e.g. PACK to NEW POOL) for a nightly file maintenance utility or invoking the DBCRE automatically. The DBCRE could be used for setting up initial header information, control or header logical records etc, performing specific indexing functions or otherwise populating the new file with initial data. The DBCLS exit could be used for conditional RELFC processing, selective de-indexing and other clean up type operations, e.g. deletes of linked or related files.
Critical Success Factors: The solution is intended primarily for TPFDF file types and should be extensible so it could accommodate from a few lines of code to perhaps even segments. The defaults should be defined so that the behavior of existing code and applications is not affected. The call to the user exit code should not have an adverse impact on the performance and result in minimal increase in path lengths. The addition of the user exits should not affect existing applications and should be transparent to users that don't require them.
Alternative Solutions: These types of functions could also be implemented as application code. However, would be difficult to have centralized control and coordination and management the business rules and data integrity requirements. Change would be and is often a continuing problem that gets progressively worse as the application ages and people are rotated in and out of the maintenance area. When changes are made to the data integrity or business rules, it is difficult to identify all of the impacted code and even more difficult to verify results through regression testing.
Solution Considerations: New DBDEF parameters or even a new sub-table that consolidates these and other user exits into one sub-table could be added. A mechanism similar to the DFLNK without the control program intercept could be used. While the user exit code would be defined in the DBDEF, an option could be provided in the application API to ignore or activate the user code for a specific instance of the command, e.g. on the DBOPN (open).