Using application filtering with the REST server

Subscriptions to the REST server may be filtered on application and library type such that event notifications are only acted on if the application (or libtype) passed on the notification matches the filter. By default all applications (and libtypes) will pass filtering. It may be that you only wish to implement REST server notification for certain specific applications, this filtering can be implemented at the REST server by coding a list of applications (separated by a semi-colon) in the relevant filter field. However, this still results in unnecessary network traffic (and delay to the application which is not taking part in event notification) as the filtering is not done until the notification reaches the REST server. ZMF has been set up to avoid this unnecessary traffic/delay by separate mechanisms for HLLX and skeleton processing. For skeleton processing file tailoring only takes place for a specific package and, as such, the application is fixed for that particular file tailoring exercise. The file tailoring programs will pass the application when they query the REST server to see if an event has any subscribers.

If the application does not pass filtering at the REST server then the file tailoring program will mark that event as 'inactive' for this process and the relevant event notification steps will not be generated in the JCL created. For HLLX the decision on whether an event is 'active' or not is taken by the main program driving the exit calls. An HLL exit call could be for any application so the same test (as for skels processing) cannot be made.

To avoid unnecessary traffic to the REST server from HLL exits you must code the application selectivity yourself in the exit code, i.e. check a list of 'REST server active' applications in your exit code prior to making a call to CMNURIRX (more information on the mechanisms used to call the REST server from both HLL exits and batch job steps is given below).