ADRDSSU Dump should generate SMF records on input datasets and volumes

IZBR uses smf records to build the Backup Table. It can process standard smf records when backups are made by various programs like IDCAMS or IEBCOPY but not from (the most commonly used backup method) ADRDSSU DUMP (or COPY). 

Now clients can set up IZBR to include data from ADRDSSU backups, where we need to enable aditional exits, setting up started tasks, assembling and linking modules and maintain configuration files. The result is JCL being modified runtime where program ADRDSSU is replaced by BRNDSSU causing the JCL to run to be different then DEVOPS have created in version control.
It is "their" JCL, it is not ours (sysprog) to just change it. IZBR does support a way to include the SMF records, but that requires changing thousands of sources. 

The function for BRNDSSU is basically to call ADRDSSU and write SMF type 202 records regarding the input datasets/volumes. This function should have been added into ADRDSSU itself so SMF processing of ADRDSSU backups can be processed like the backups from other programs without additional install, configure and maintaining by clients. Even though ADRDSSU does not implicitly opens datasets for input, it does know what datasets/volumes it has backed up. All it needs to do is create some SMF records for it. The solution is perhaps already there, imbed the BRNDSSU coding into the ADRDSSU module itself. 

The current options are insufficient viable for our shop to implement to have a complete build of the backup table.  

In short: If the problem is that ADRDSSU does not generate the needed smf records, then the solution is to have it do just that. 
 
These new SMF records could be suppressed by default where clients can choose to have these records produced by setting a parameter in DEVSUPxx.