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
