How IBM Fault Analyzer for z/OS can help you with GDPR compliance

By now you would be aware that the European Union (EU) General Data Protection Regulation (GDPR) will be enforced from May 25th 2018. The GDPR is designed to protect all EU citizens from privacy and data breaches and applies to any organization that operates in the EU market or processes the personal data of EU citizens. To learn more about the GDPR visit https://www.eugdpr.org/.
​

There will be stiff penalties for organizations that fail to abide by the GDPR rules so remaining compliant is critical. Compliance applies to many areas of an organization, including application development and support and IBM Fault Analyzer for z/OS provides some features that can help.

Controlling access to fault entries
Fault Analyzer captures and stores information relating to an application abend in a fault entry. Each fault entry is stored as a separate member in a partitioned data set known as a fault history file. The information saved in the fault entry member allows development and support staff to use Fault Analyzer to perform analysis of an application abend.

For an abend in a production application, the information saved in the fault entry could include sensitive data such as customer personal details. If this is the case, sites will want to restrict access to these fault entries to those application support staff with the appropriate security clearance to deal with sensitive data. Controlling access to these fault entries could be handled using the site’s security product (e.g. RACF®) and restricting access to the data set profile for the history file.

This approach, however, may not provide the granularity needed by sites wanting to manage access to individual fault entries. For these sites, Fault Analyzer enables the ability to restrict access to individual fault entries using the XFACILIT resource class and universal access of NONE for the fault entry data set profile. Fault Analyzer supports two XFACILIT resource classes for this purpose – one is based on the GROUP ID of the user who initially created the fault entry and the other based on the USER ID of the user who initially created the fault entry. This allows a site, for example, to restrict access to fault entries created by a particular user in the payroll department to application support staff with the appropriate security clearance to view payroll information.

When a user tries to perform an action against a fault entry and access is denied through the history file data set profile, Fault Analyzer checks if the user has been given access through either of the two XFACILIT resource classes. If so, the action against the fault entry is permitted.

A further level of access control is provided with the IDIXFXIT user exit. This optional exit is called when authorization to perform an action against a fault entry is not granted via the history file data set profile and the XFACILIT resource classes. The exit is passed the fault entry access required by the user and the exit return code to Fault Analyzer indicates whether that access is granted. Fault Analyzer also passes fault entry environment information related to the abend including Job Name, User ID, Program Name and CICS transaction ID. So the exit is provided with a lot of information it can use in deciding whether access should be granted. 

For further information on managing access to fault entries see
https://www.ibm.com/support/knowledgecenter/SSXJAJ_14.1.0/com.ibm.faultanalyzer.doc_14.1/xfacilhist.html.

​Sending fault entries to a particular history file
A number of user exits are available to allow sites to customize Fault Analyzer operations. The End Processing user exit is provided to allow control over the post-analysis actions taken by Fault Analyzer. One of those actions is selecting the history file to store the fault entry. An End Processing user exit could use environment information passed by Fault Analyzer to decide on the history file where the fault entry will be stored. The environment information passed to the exit provides many data items that can be used to identify the application generating the fault, including the Job Name, Program Name, abending module name and CICS transaction ID. The environment information also provides the user ID associated with the abending job or transaction. Using this environment information an End Processing exit could, for example, direct any fault entries from a customer accounts application to a fault history file that can only be accessed by application support staff with security clearance to analyze faults that may contain sensitive customer information.

For further information on the End Processing user exit see
https://www.ibm.com/support/knowledgecenter/SSXJAJ_14.1.0/com.ibm.faultanalyzer.doc_14.1/uexend.html#uexend.

Peter Van Dyke
Senior Solution Architect ​

---

Peter Van Dyke is a Senior Solution Architect in Lab Services with HCL Technologies, specializing in DevOps on IBM System z. Prior to joining HCL Technologies Peter spent over 27 years working in z systems software development with IBM. During his time with IBM Peter worked on the development of a wide range of System z products including COBOL compilers and runtime libraries, Language Environment, Debug Tool, Fault Analyzer, and File Manager. For 14 years Peter was the architect and lead developer for Interactive System Productivity Facility (ISPF). In this role Peter had the opportunity to provide ISPF training to IBM staff and customers and to present education sessions at conferences including the SHARE conference held biannually in the US. Peter has also provided training to z/OS customers in the use of File Manager, Fault Analyzer, Debug Tool, and Application Performance Analyzer.