IPT Exit Point Integration

The design of IPT means that "certain ISV monitoring products" will see SVCs issued by the same module name for a wide variety of different functions. Some of these functions could represent "interesting" references to individual members, others could represent changes to members, and others (like global search) are "uninteresting" and could be ignored by "certain ISV monitoring products". This suggests that IPT needs some way to tell these "certain ISV monitoring products" what it wants to do.

This requirement is for IPT to incorporate some user exit points to enable these "certain ISV monitoring products" to be able to provide user exits that would be called at those exit points. IPT would need to call these exits for all functions performed by the relevant programs, and, given the presence of the exits, "certain ISV monitoring products" could then ignore certain actions of the specific programs in its normal SVC hooks. These "certain ISV monitoring products" would then be able to perform processing for these specific IPT programs in the user exits.

Among other things, this user exit would need to receive (at least):
- an indication of what function is being performed
- an indication of whether the data set is opened for input or output
- data set name
- new data set name if data set rename
- DSORG
- member name (if partitioned)
- new member name if member rename (if partitioned)
- volume ID
- DDname

For read-only operations, a post-operation exit would suffice, while for
non-input operations, a pre-operation exit and a post-operation exit
would be required. The pre-operation exit would need the capability to
reject the operation.