my $audit_trail = $ENV{AUDIT_LEVEL} || 0; #### ## LOG ## Process: daily_upd started at 00:30:00 25 Mar 2000 Data source: /data/input/daily.dat Data sink: database customer on server DATA_SERVER (using id 'maint') Input record: D:CUS-00123 Action: Delete Translation: CUS-00123 = database id 2364 Record 2364 deleted successfully Input record: U:CUS-00124:Jones & Co| [etc …] Action: Update Translation: CUS-00124 = database id 2365 Record 2365 updated successfully Input record: I:CUS-01000:Magnum Solutions Ltd| [etc …] Action: Insert Integrity Check: CUS-01000 does not exist on database Record 3159 inserted successfully End of file on data source 1037 records processed (60 ins, 964 upd, 13 del) Process: daily_upd complete at 00:43:14 25 Mar 2000 #### At different points in the life of a program, different levels of auditing will be appropriate. While the program is being developed and tested it is common practice to have a much more detailed audit trail than when it is being used day to day in a production environment. For this reason, it is often useful to write auditing code that allows you to generate different levels of output depending on the value of a variable that defines the audit level. This variable might be read from an environment variable like this: my $audit_level = $ENV{AUDIT_LEVEL} || 0; In this example we set the value of $audit_level from the environment variable AUDIT_LEVEL. If this level is not set then we default to 0, the minimum level. Later in the script we can write code like: print LOG 'Starting processing at ', scalar localtime, "\n" if $audit_level > 0; to print audit information to the previously opened file handle, LOG. Standards for audit trails will typically vary from company to company, but some things that you might consider auditing are:  start and end times of the process  source and sink parameters (filenames, database connection parameters, etc.)  ID of every record processed  results of each data translation  final count of records processed