Following up on my last post about Error Report Contents I’d like to identify 4 ways an error report can be distributed.
Error reports can be distributed in the following manner;
Mainframe or application logs: Such reports can be deleted when the time limit has been reached. This will take space and has limited search capabilities.
Email alerts: Great for filing up your inbox. If you’re ambitious enough you can sort, organize, follow-up or delete them.
Webpages: Having them on web pages provides that modern look and feel and provides access to anyone you wish. You can then drill down to gather further details on the error, job, and even further details. Can be a bit cumbersome to manage.
Database tables: In this form you can query the results, and maintain a history in an easy to read format, provided you have the right skills.
Recommendation: Regardless of how you look at it. In a support role, you need to action incidents quickly. To do that use email alerts, once completed you can delete them and keep your inbox clean. Furthermore, you want to report on them, so only delete them if you have a record of them elsewhere. The best bet is to have your errors written to a database table where you can create some KPI’s on files or even source systems (another tidbit to keep in mind for error reports). SQL will allow you to create some good KPI’s and identify key trouble areas. With those indicators you will be able to take corrective actions on systems and files that just don’t measure up to any service level agreements you may have in place.
