In many IBM i environments, business-critical batch processes have been running smoothly and reliably for years.  

At the same time, however, the requirements for traceability, auditability and compliance are constantly increasing. 

Traditional log files quickly reach their limits in this context: they are incomplete in the event of crashes, difficult to analyse, or susceptible to subsequent alterations. 

This article outlines a practical approach to implementing robust and audit-proof logging using the built-in features of IBM i (version 7.1 and later) – without the need for additional infrastructure and with minimal effort. 

Initial situation 

Typical challenges in existing batch processes: 

• Log files are incomplete if a job is aborted 

• The causes of errors can only be traced in the job log 

• There is no clear link between: 

• File 

• Processing 

• Result 

• There is no evidence of tampering with the log 

• Character set issues complicate further processing 

This can quickly become a critical issue, particularly in the context of audits or regulatory requirements. 

Target: Audit-proof logging 

The solution presented has a clear objective: 

All processing must be documented in full, in a manner that is traceable and verifiable – even in the event of an error. 

A multi-level logging approach is used for this purpose. 

An overview of the approach 

The solution is based on three key components: 

1. Continuous RAW logging

During processing, all events are written directly to a RAW log file. 

•  Advantage: Even if the programme is interrupted, all the information entered so far is retained.

2. Final log with a defined structure

At the end of the processing, the RAW log is converted into a final log file: 

• specified CCSID (e.g. Windows 1252 or UTF-8) 

• Consistent structure 

• optimised for further processing 

-> Advantage: The log can be used directly for tools, analysis or archiving. 

 3. Proof of integrity via hash

In addition, a hash (e.g. SHA-256) is generated for the final log file and stored separately. 

-> Advantage: Any subsequent changes to the log can be clearly traced. 

Added value in detail 

Full transparency for each file 

For each file processed, the following information is logged, amongst other things: 

• Source directory and file name 

• Destination directory (DONE / ERROR) 

• New file name including timestamp 

• Number of imported records 

• Result of the processing 

This ensures clear, comprehensive documentation.

Structured fault analysis 

Errors are treated differently: 

• Known issues with message ID and plain text 

• Unknown errors with classification 

•  Result: Errors can be analysed without having to check the job log. 

Contextual information for audits 

Each run contains relevant system information: 

• Job name, user and job number 

• System environment (e.g. test / production) 

• client 

• programme used 

•  Advantage: The processing can be clearly assigned to a system context. 

Traceability over time 

Each log entry is assigned its own timestamp. 

• Advantage: Precise reconstruction of the sequence and analysis of execution times are possible 

Proof of data integrity 

In addition to the log itself, the input files are also documented: 

• Filesize

• Checksums / Hash values 

• Advantage: It is clear which specific file has been processed. 

Flexible hashing algorithm 

The hashing process is configurable: 

• automatic selection (OpenSSL with fallback) 

• targeted use of SHA-256 

• or maximally compatible via cksum 

•  Advantage: The solution adapts to different system environments. 

Protection against tampering 

Once created, the following will be: 

• Log files set to read-only 

• Hash files stored in a separate, protected directory 

-> Advantage: Tampering is made more difficult and can be detected. 

Reliable in batch mode 

The complete solution is: 

• fully CL-based 

• Compatible with IBM i 7.1 and later 

• Runs without additional tools (fallback mechanisms in place) 

• Advantage: It can be easily integrated into existing processes. 

Conclusion 

With this approach, logging evolves from a simple tool into a genuine component of the system architecture. 

The main effects: 

• Greater transparency in batch processes 

• Faster fault diagnosis 

• Auditability and compliance with auditing requirements 

• High durability, even in the event of interruptions 

This is a crucial step, particularly in regulated environments or where compliance pressures are mounting.