Classification: Confidential I would share devices at the physical level (all devices can be brought online to any LPAR) I would not share those devices at the logical level (all devices are offline where not normally used).
HTH, -----Original Message----- From: IBM Mainframe Discussion List <[email protected]> On Behalf Of Ituriel do Neto Sent: Friday, November 25, 2022 6:42 AM To: [email protected] Subject: Re: To share or not to share DASD [CAUTION: This Email is from outside the Organization. Unless you trust the sender, Don’t click links or open attachments as it may be a Phishing email, which can steal your Information and compromise your Computer.] Hi, In the past, i used to work for a tiny shop with the same distribution you indicated. Only three Lpars and no Sysplex, no GRS. At that time, we choose to make all disks available to all Lpars, but there was a segregation of Production, Development, and Sysprog volumes done by VOLSER. I don't remember the details anymore, but shared disks were labeled as SHR*, Production and development disks as PRD* and DEV*, and of course SYSRES, Page, spool, etc... At IPL time, a small program was executed, searching all volumes and issuing V OFFLINE to those that do not belong to the appropriated Lpar. This program used wildcard masks to select what should remain ONLINE. And, of course, MVS commands were protected in RACF, so only authorized userids can VARY ONLINE a volume. It worked well for us, in this reality. Best Regards Ituriel do Nascimento Neto z/OS System Programmer Em sexta-feira, 25 de novembro de 2022 02:38:47 BRT, Joel C. Ewing <[email protected]> escreveu: But its not just a case of whether you trust they will not intentionally damage something, but the ease of accidentally causing integrity problems by not knowing when others have touched catalogs, volumes, or datasets on DASD that is physically shared but not known to be shared by the Operating System. If many people are involved, the coordination procedures involved to prevent damage, assuming such procedures are even feasible, are a disaster waiting to happen. If volumes are SMS, all datasets must be cataloged and the associated catalogs must be accessed from any system that accesses those datasets. If the systems are not in a relationship that enables proper catalog sharing, access and possible modification of the catalog from multiple systems causes the cached versions of catalog data to become out of sync with actual content on the drive when the catalog is altered from a different system, and there is a high probability the catalog will become corrupted on all systems. Auditors are justified in being concerned whether independent RACF databases on multiple systems will always be in sync to properly protect production datasets from unintentional access or unauthorized access if test LPARs share access to production volumes. There should always be multiple barriers to doing something bad because accidents happen -- like forgetting to change a production dataset name in what was intended to be test JCL. There are just two many bad things that can happen if you try to share things that are only designed for sharing within a sysplex. The only relatively safe way to do this across independent LPARs is non-concurrently: have a set of volumes and a catalog for HLQ's of just the datasets on those volumes that is also located on one of those volumes, and only have those volumes on-line to one system at a time and close, and deallocate all datasets and the catalog on those volumes before taking them offline to move them to a different system. A much simpler and safer solution is to not share DASD volumes across LPARs not in the same sysplex, to maintain a unique copy of datasets on systems where they are needed, and to use a high-speed communication link between the LPARs to transmit datasets from one system to another when there is a need to resync those datasets from a production LPAR. Joel C Ewing On 11/24/22 21:38, Farley, Peter wrote: > 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 > -- > ... -- Joel C. Ewing ---------------------------------------------------------------------- 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 ::DISCLAIMER:: ________________________________ The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. E-mail transmission is not guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or may contain viruses in transmission. The e mail and its contents (with or without referred errors) shall therefore not attach any liability on the originator or HCL or its affiliates. Views or opinions, if any, presented in this email are solely those of the author and may not necessarily reflect the views or opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of authorized representative of HCL is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any email and/or attachments, please check them for viruses and other defects. ________________________________ ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
