That's why off-site backup, outside of the range of regional disasters, are so important. Data centers have been destroyed by earthquakes, industrial accidents and weather in the past, and RAID offers no protection.
Hot backup and its cousins are no longer arcane topics. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 ________________________________________ From: IBM Mainframe Discussion List [[email protected]] on behalf of Colin Paice [[email protected]] Sent: Friday, November 25, 2022 9:34 AM To: [email protected] Subject: Re: To share or not to share DASD I had to explain to some people that RAID disks do not give 100% protection. If you delete a file or corrupt a file, then the RAID will *reliably* make the change to delete or corrupt all copies of the data. We used z/VM and ran z/OS on top of it. We could share volumes read only and so people could not change them. Colin On Fri, 25 Nov 2022 at 13:45, Seymour J Metz <[email protected]> wrote: > I don't even trust myself; belt and suspender policies are highly useful > in a development environment. The key is to deploy safeguards that don't > get underfoot. Have you never had to revert a change? > > Auditors serve a useful purpose. Get rid of the bad ones, not all. > > > -- > Shmuel (Seymour J.) Metz > http://mason.gmu.edu/~smetz3 > > ________________________________________ > From: IBM Mainframe Discussion List [[email protected]] on behalf > of Farley, Peter [[email protected]] > Sent: Thursday, November 24, 2022 10:38 PM > To: [email protected] > Subject: Re: To share or not to share DASD > > Not necessarily true in a software development environment where all > members of the team need to share all their data everywhere. "Zero trust" > is anathema in a development environment. > > If you don't trust me then fire me. It's cleaner that way. > > Shakespeare was *almost* right. First get rid of all the auditors, *then* > get rid of all the lawyers. > > Peter > > -----Original Message----- > From: IBM Mainframe Discussion List <[email protected]> On Behalf > Of Lennie Dymoke-Bradshaw > Sent: Thursday, November 24, 2022 5:24 PM > To: [email protected] > Subject: Re: To share or not to share DASD > > If you were asking in a security context, I would advise against it in > nearly all cases. > Auditors will not like that a system's data can be accessed without > reference to the RACF (or ACF2, or TSS) system that is supposed to protect > it. > > Lennie Dymoke-Bradshaw > > -----Original Message----- > From: IBM Mainframe Discussion List <[email protected]> On Behalf > Of Gord Neill > Sent: 24 November 2022 20:55 > To: [email protected] > Subject: To share or not to share DASD > > G'day all, > I've been having discussions with a small shop (single mainframe, 3 > separate LPARs, no Sysplex) regarding best practices for DASD sharing. > Their view is to share all DASD volumes across their 3 LPARs > (Prod/Dev/Test) so their developers/sysprogs can get access to current > datasets, but in order to do that, they'll need to use GRS Ring or MIM with > the associated overhead. I don't know of any other serialization products, > and since this is not a Sysplex environment, they can't use GRS Star. I > suggested the idea of no GRS, keeping most DASD volumes isolated to each > LPAR, with a "shared string" > available to all LPARs for copying datasets, but it was not well received. > > Just curious as to how other shops are handling this. TIA! > > > Gord Neill | Senior I/T Consultant | GlassHouse Systems > -- > > 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 [email protected] with the message: INFO IBM-MAIN > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to [email protected] with the message: INFO IBM-MAIN > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
