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

Reply via email to