I don't know about your experience, but the industry in which I work in has some legal and some client-initiated retention rules that require retaining records for as long as 7 calendar years, so we have GDG's for all such "permanent" files and can usually go back to select appropriate data to rerun tests.
Some clients also require fuller sets of "historical" data for several internal processing phases be available for business purposes for shorter but not insignificant periods like 3-6 months. I've hardly ever had a case where I couldn't find the data to replicate a past processing issue somewhere in one or more of those GDG's, and then usually only when a client fails to report an issue until their requested retention period has expired. Many shops still have quite a lot of processing in overnight batch using GDG's for input and output, and what isn't batch usually has some form of sequential GDG backups for some length of time, so data sharing issues versus production work shouldn't usually happen. As for HIPAA and PII in general, it definitely depends on the percentage of such data in the processing stream, and whether it is isolated to reference data that can more easily be masked for programmer testing or whether (as I suspect could be true in Mr. Reichman's case) the vast proportion of the transactional data is PII. In my company the PII is pretty much isolated to maskable amounts of reference data, and what isn't maskable is locked down and stored with encryption. Programmers who have to deal with locked-down PII data have a steeper hill to climb to get their testing done. To paraphrase the B. Joel song, it's always been a matter of "trust but verify". Company and management culture and practice have a lot to do with how hard that is to do. Peter -----Original Message----- From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> On Behalf Of Seymour J Metz Sent: Friday, March 26, 2021 6:09 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Dataset contention There are both legal and operational issues with programmer access to live data, e.g., HIPPA, ENQ. Further, once you have successfully reproduced a bug, best practice requires that the corrected code produce the correct answer with the data that the previous version failed on. Doing so requires frozen test data. -- Shmuel (Seymour J.) Metz https://urldefense.com/v3/__http://mason.gmu.edu/*smetz3__;fg!!Ebr-cpPeAnfNniQ8HSAI-g_K5b7VKg!amekN-DCxmbzGSuqbRSemgMgAzndRbuzJpGNETv9ygXAkl55GiNGLz0CJNTI8VK6NzEJFQ$ ________________________________________ From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Farley, Peter x23353 [0000031df298a9da-dmarc-requ...@listserv.ua.edu] Sent: Friday, March 26, 2021 1:47 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Dataset contention Jeremy, I have to disagree with you here about access to read (not modify) production data by application developers. Full read access to production data (especially when the quantities are very large and cannot easily be copied to "test" disk pools which are usually much smaller than production) is a critical problem solving and research tool. I deal with very large quantities of "production" data every day for both client issue resolution and business function enhancement research. Simple examples are "How many widgets does client xyz process in a day? In a week? In a month? And what application characteristics did we apply to the client processing of that widget (or ones of similar type abc)?". I do understand that possible malfeasance by bad-actor "insiders" like application programmers is considered a business risk, but the solution is not to prevent normal, every-day read access to those insiders, but to limit the actual PII data available to them via masked files. In the case that even masking files is difficult or impossible due to the inherent vast volume of the data, the only reasonable real-world solution is "trust but verify" your employee's activities. Denying access by programmers to production data is a disaster all by itself for any kind of reasonable and necessary client issue resolution time scale and for reasonable business function enhancement research timelines. I do agree that PII data should usually be masked for application programmer access if at all possible (it certainly is where I work), but in the Mr. Reichman's case just about the entire data contents is PII. "Trust but verify" is the only reasonable business solution in his case, absent vast duplication of huge quantities of data for masked copies. And remember our tax dollars have to pay for that duplication. Various implementations of so-called "break glass" procedures to assign special temporary system identifiers for programmers to gain access to un-masked production data frequently ignores the fact that the programmer also needs access to all their non-production tools and libraries while using the production data. I have never seen such a process that actually works when time is of the essence (e.g., a serious production-stopping issue). Peter -----Original Message----- From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> On Behalf Of Jeremy Nicoll Sent: Friday, March 26, 2021 11:17 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Dataset contention <Snipped> > if it's > corrupted I can run it again it won't happen and like I said it's not > production if it was that would change things I really don't understand how you can be trawling through vast amounts of tax (IIRC) data, and it not be production. I mean, it's live datasets, is it not? Surely you wouldn't have access to that data unless there was a proper authorised use-case. Re-running jobs just wastes system resources. Does nobody supervise what you and your colleagues do? -- This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
