.Our technical architect and Release Coordinator would like a "SUMMARY" report along with the main audit report. The "SUMMARY" report would identify the Audit Errors only. Currently we've been asked to build automation that reads the audit report, finds only the errors and send those errors to the appropriate development teams. This was difficult to do because the current Audit report has so much information. Reading the report and parsing through it to get only the error information was difficult to do. The Summary report would allow them to send that report to development personal who's packages have an error. They can go to the main report if they need more information. It would be nice to be able to run those audit reports and put them to files, especially for ERO. That way you can notify the developers the location of the audit reports.
.Our technical architect and Release Coordinator would like a "SUMMARY" report along with the main audit report. The "SUMMARY" report would identify the Audit Errors only. Currently we've been asked to build automation that reads the audit report, finds only the errors and send those errors to the appropriate development teams. This was difficult to do because the current Audit report has so much information. Reading the report and parsing through it to get only the error information was difficult to do. The Summary report would allow them to send that report to development personal who's packages have an error. They can go to the main report if they need more information. It would be nice to be able to run those audit reports and put them to files, especially for ERO. That way you can notify the developers the location of the audit reports.
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
.Our technical architect and Release Coordinator would like a "SUMMARY" report along with the main audit report. The "SUMMARY" report would identify the Audit Errors only. Currently we've been asked to build automation that reads the audit report, finds only the errors and send those errors to the appropriate development teams. This was difficult to do because the current Audit report has so much information. Reading the report and parsing through it to get only the error information was difficult to do. The Summary report would allow them to send that report to development personal who's packages have an error. They can go to the main report if they need more information. It would be nice to be able to run those audit reports and put them to files, especially for ERO. That way you can notify the developers the location of the audit reports.
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.
.Our technical architect and Release Coordinator would like a "SUMMARY" report along with the main audit report. The "SUMMARY" report would identify the Audit Errors only. Currently we've been asked to build automation that reads the audit report, finds only the errors and send those errors to the appropriate development teams. This was difficult to do because the current Audit report has so much information. Reading the report and parsing through it to get only the error information was difficult to do. The Summary report would allow them to send that report to development personal who's packages have an error. They can go to the main report if they need more information. It would be nice to be able to run those audit reports and put them to files, especially for ERO. That way you can notify the developers the location of the audit reports.
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.
.Our technical architect and Release Coordinator would like a "SUMMARY" report along with the main audit report. The "SUMMARY" report would identify the Audit Errors only. Currently we've been asked to build automation that reads the audit report, finds only the errors and send those errors to the appropriate development teams. This was difficult to do because the current Audit report has so much information. Reading the report and parsing through it to get only the error information was difficult to do. The Summary report would allow them to send that report to development personal who's packages have an error. They can go to the main report if they need more information. It would be nice to be able to run those audit reports and put them to files, especially for ERO. That way you can notify the developers the location of the audit reports.
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.
.Our technical architect and Release Coordinator would like a "SUMMARY" report along with the main audit report. The "SUMMARY" report would identify the Audit Errors only. Currently we've been asked to build automation that reads the audit report, finds only the errors and send those errors to the appropriate development teams. This was difficult to do because the current Audit report has so much information. Reading the report and parsing through it to get only the error information was difficult to do. The Summary report would allow them to send that report to development personal who's packages have an error. They can go to the main report if they need more information. It would be nice to be able to run those audit reports and put them to files, especially for ERO. That way you can notify the developers the location of the audit reports.
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.
Sign up
Already have an account? Login
Welcome to the Rocket Forum!
Please log in or register:
Employee Login | Registration Member Login | RegistrationEnter your E-mail address. We'll send you an e-mail with instructions to reset your password.