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 <sme...@gmu.edu> 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 [IBM-MAIN@LISTSERV.UA.EDU] on behalf
> of Farley, Peter [0000031df298a9da-dmarc-requ...@listserv.ua.edu]
> Sent: Thursday, November 24, 2022 10:38 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> 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 <IBM-MAIN@LISTSERV.UA.EDU> On Behalf
> Of Lennie Dymoke-Bradshaw
> Sent: Thursday, November 24, 2022 5:24 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> 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 <IBM-MAIN@LISTSERV.UA.EDU> On Behalf
> Of Gord Neill
> Sent: 24 November 2022 20:55
> To: IBM-MAIN@LISTSERV.UA.EDU
> 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
> ----------------------------------------------------------------------
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Reply via email to