This request has been addressed in ZMF 8.3 for both ERO and package audits.  

For those looking for something for package audit ahead of this you might want to consider the ability the generate a CSV summary of audit errors. I'm not sure that this has made the documentation yet but the summary is this...

‘Comma Separated Value’ summary of audit errors

Audit (CMNAD500) will now, optionally, output a CSV record for each error reported. These CSV records can be downloaded to a PC and opened using excel, or loaded up into a DB2 table, or processed in any way the customer sees fit.

The format of the CSV record is most easily described using the sample DDL supplied for creating a DB2 table to take these values (see below). Sample JCL member CMNDB2CS supplies the JCL/DDL required to both create this table and to load it from the CSV file.

If the customer wishes to make use of this facility they need only allocate the following ddname to the CMNAD500 step in their audit job:

//*                                                                     

//AD500   EXEC PGM=CMNAD500,   *** FORMAT AUDIT REPORT                  

//             PARM='SUBSYS=8,USER=WSER58,SUP=NO'                       

//*)IM CMN$$SPR                                                          

//SER#PARM DD  DISP=SHR,DSN=…                   

//SYSPRINT DD  SYSOUT=*                                                 

//ABNLIGNR DD  DUMMY                                                    

//SYSUDUMP DD  SYSOUT=*                                                 

//AUDIT10  DD  DISP=(OLD,DELETE),DSN=&&SORT10                           

//AUDIT20  DD  DISP=(OLD,DELETE),DSN=&&SORT20                           

//AUDIT30  DD  DISP=(OLD,DELETE),DSN=&&SORT30                            

//AUDITRPT DD  SYSOUT=*  

//CMNCSV01 DD  DISP=OLD,DSN=your.audit.csv.file                                              

This sequential file should be allocated as RECFM=VB,LRECL=700,BLKSIZE=0

The variables in each record of the file are described thus:

TARGET_PKG          CHAR(10)      NOT NULL WITH DEFAULT,   

TOP_NAME            VARCHAR(256)  NOT NULL WITH DEFAULT,   

TOP_LIBTYPE         CHAR(3)       NOT NULL WITH DEFAULT,   

TOP_BASE_SETSSI     CHAR(8)       NOT NULL WITH DEFAULT,   

TOP_BASE_TIME       TIMESTAMP     NOT NULL WITH DEFAULT    

                                      '1900-01-01-00.00.00',

TOP_BASE_USERID     CHAR(8)       NOT NULL WITH DEFAULT,   

TOP_STAGE_PKG       CHAR(10)      NOT NULL WITH DEFAULT,   

TOP_STAGE_SETSSI    CHAR(8)       NOT NULL WITH DEFAULT,   

TOP_STAGE_TIME      TIMESTAMP     NOT NULL WITH DEFAULT    

                                      '1900-01-01-00.00.00',

TOP_STAGE_USERID    CHAR(8)       NOT NULL WITH DEFAULT,   

SYNCH_ERROR         CHAR(2)       NOT NULL WITH DEFAULT,   

BOTTOM_NAME         VARCHAR(256)  NOT NULL WITH DEFAULT,   

BOTTOM_PKG          CHAR(10)      NOT NULL WITH DEFAULT,   

BOTTOM_SETSSI       CHAR(8)       NOT NULL WITH DEFAULT,   

BOTTOM_TIME         TIMESTAMP     NOT NULL WITH DEFAULT    

                                      '1900-01-01-00.00.00',

BOTTOM_USERID       CHAR(8)       NOT NULL WITH DEFAULT   

For non-relational errors (i.e. not copybook or subroutine errors) only the ‘TOP’ fields are used.

BASE fields contain the values for the baseline version of the component, STAGE from the staging version. If a value doesn’t exist (e.g. not in baseline) then the field is represented by an adjacent comma (as you would expect).

Non-load module info has no SETSSI value.

Load module info has the SETSSI value and the provided timestamp is derived directly from that setssi value.

Relational errors (synch4 etc.) make use of the TOP BASE and STAGE fields to describe the affected top level component and the BOTTOM fields to describe the subcomponent causing the error.

i agree with summary. i think  a summary that showed all synch errors to be addressed in one place instead of having to search report would be a great change.

Following feedback from the submitter, we are adding the requirements mentioned on this Idea to the existing enhancement request (ENH165721).  ENH165721 will cater for the similar requirement in both base audit and ERO audit.

I always have issues with getting users to read and find the components to be resolved especially when a source/load issue.

I think this is a great IDEA to see all errors to be corrected in one place and easy to understand format.

Thank you for submitting the idea.  We have a couple of questions to help us further understand your use case.

1. Is your request in regards to package audit, or ERO audit?
We have an existing enhancement (ENH165721) for package audit, which closely matches your description of generating a summary audit to contain only the detail for SYNCH errors.

2. Do you have a prototype of the summary report you would like to generate?

Thanks