Data protection and compliance is such an important topic, and there’s no exception on mainframe. But it can be complex to implement for mainframe, particularly in relation to what we sometimes term as “legacy” mainframe data sources. This blog post discusses why it is difficult, and how data masking on legacy mainframe data sources can be done.
In “modern” mainframe databases such as DB2, metadata is readily available to describe each and every field within a table. This data is typically held within a set of system tables that can easily be referenced by applications. In the case of DB2, this information is collectively known as the DB2 Catalog.
Jump back 40 years (yes, frightening isn’t it!) or more, and the situation is not so straightforward.
Legacy data structures required ‘Data dictionaries’
Users of what many of us consider to be primitive data structures, such as fixed and variable length flat files, VSAM files and early databases such as the hierarchical IMS and Networked IDMS, did not have such an easy life. Data dictionaries were developed to keep track of data usage within such table structures. But there was still a dependence on external language dependant data structures such as COBOL COPYBOOKS and PL/I INCLUDE members, together with the necessity for often manual scanning of the (tens of thousands of) application programs that might access these data sources, to get a full understanding of exactly which record contained which data and at which point in time.
Despite some organisations having whole “Data dictionary” teams of former developers and designers assigned to keep these devices up-to date, often such activity fell outside of the organisations change management process, and led to issues down the line.
Modern data privacy requirements are myriad and strict
With the introduction of compliance initiatives such as GDPR and CCPA, the processing of data sources within organisations become a major focus. In production, access to the data is restricted to only those who need it. But in test environments, the story is more complex. Production data (‘real’ data which covers valid scenarios) is required in test environments to enable high quality testing, but the data must remain secured to ensure data compliance.
Data obfuscation, or masking to those of us who cannot pronounce it (you know who you are), needs to be applied to ALL data sources that hold personally identifiable information (PII). In the mainframe teams, this covers DB2, IMS, IDMS, VSAM, flat files and even MQ messages, etc.
Modern day metadata needs to be acquired, unravelled, documented and verified so that masking can be performed adequately to protect the identity of every individual. Notably, masking also has to be performed in a simple and consistent way across an entire organisation’s estate – including mainframe and distributed platforms.
How to mask legacy data structures in a simple and consistent way?
Delphix Continuous Compliance Engine provides excellent data compliance capabilities for most data types. In conjunction with Delphix, PopUp’s z/OS Masking Plugin for Delphix, provides a simple solution for masking legacy mainframe data sources consistently.
With the PopUp masking plugin, VSAM files, IMS databases and data from any mainframe database (that can be unloaded to/reloaded from flat files) can now be processed for masking. COBOL copybooks and PL/I Includes can be processed effortlessly, allowing the Delphix Profiler to work its magic and identify and allocate algorithms based on the data formats.
Data residing in these ‘legacy’ mainframe data sources can be processed by Delphix Continuous Compliance (via the PopUp masking plugin). This means that data from sources across an organisation can be represented and treated (masked) in the same way, reducing the need for specific mainframe expertise.
For more information on the z/OS Masking Plugin for Delphix, watch our video.
If you have data compliance requirements for legacy mainframe data sources, we can help! Get in touch to hear more.
Follow us on LinkedIn