Storing content of an audit report within ChangeMan accelerates development because no tool-change (e.g. to SDSF) and additional time for searching has to be performed. 

During our last internal ChangeMan -training some developers asked, if it wouldn't be a good idea to store content of an Audit Report (Package and Release) within ChangeMan.
The advantage would be that in doing that, audit-information is directly accessible within ChangeMan (without changing to SDSF or what ever) and that the last audit-report for a package or a release could also be baselined (like program-listings). This also may be obtained as a unchangeable proof with which audit-result the package (or release) went to production.
We think there are much more arguments to find when dealing with this idea in deepth.

Storing content of an audit report within ChangeMan accelerates development because no tool-change (e.g. to SDSF) and additional time for searching has to be performed. 

During our last internal ChangeMan -training some developers asked, if it wouldn't be a good idea to store content of an Audit Report (Package and Release) within ChangeMan.
The advantage would be that in doing that, audit-information is directly accessible within ChangeMan (without changing to SDSF or what ever) and that the last audit-report for a package or a release could also be baselined (like program-listings). This also may be obtained as a unchangeable proof with which audit-result the package (or release) went to production.
We think there are much more arguments to find when dealing with this idea in deepth.

Storing content of an audit report within ChangeMan accelerates development because no tool-change (e.g. to SDSF) and additional time for searching has to be performed. 

During our last internal ChangeMan -training some developers asked, if it wouldn't be a good idea to store content of an Audit Report (Package and Release) within ChangeMan.
The advantage would be that in doing that, audit-information is directly accessible within ChangeMan (without changing to SDSF or what ever) and that the last audit-report for a package or a release could also be baselined (like program-listings). This also may be obtained as a unchangeable proof with which audit-result the package (or release) went to production.
We think there are much more arguments to find when dealing with this idea in deepth.

Storing content of an audit report within ChangeMan accelerates development because no tool-change (e.g. to SDSF) and additional time for searching has to be performed. 

During our last internal ChangeMan -training some developers asked, if it wouldn't be a good idea to store content of an Audit Report (Package and Release) within ChangeMan.
The advantage would be that in doing that, audit-information is directly accessible within ChangeMan (without changing to SDSF or what ever) and that the last audit-report for a package or a release could also be baselined (like program-listings). This also may be obtained as a unchangeable proof with which audit-result the package (or release) went to production.
We think there are much more arguments to find when dealing with this idea in deepth.

Storing content of an audit report within ChangeMan accelerates development because no tool-change (e.g. to SDSF) and additional time for searching has to be performed. 

During our last internal ChangeMan -training some developers asked, if it wouldn't be a good idea to store content of an Audit Report (Package and Release) within ChangeMan.
The advantage would be that in doing that, audit-information is directly accessible within ChangeMan (without changing to SDSF or what ever) and that the last audit-report for a package or a release could also be baselined (like program-listings). This also may be obtained as a unchangeable proof with which audit-result the package (or release) went to production.
We think there are much more arguments to find when dealing with this idea in deepth.