Re: Subject: To share or not to share DASD

[Ed Jaffe]

On 11/25/2022 6:22 AM, Don Parrott wrote:

We created a DASD only SYSPLEX about 3(?) years ago on a z/14 primarily to facilitate 
PDSE sharing between the PROD and DEVL lpars.   I would have rather had a coupling 
facility for a full sysplex, but we did not have one.There was a ton of work to 
setup the CTC pairs between the three lpars, the final one being our maintenance 
lpar.   GRS will have to be reviewed carefully.We have had zero issues since 
implementation.   Feel free to write me directly for specific questions.   
d...@clemson.edu


No doubt setting up CTC connections is more work than simply setting up 
a CF messaging structure, but they're good to have in case you want to 
use/test GRS ring, push VTAM or XCF traffic through a dedicated 
resource, connect to non-z/OS LPARs such as z/VM or z/VSE without going 
through an OSA, etc.


Years ago, Skip Robinson gave a nice explanation (perhaps at SHARE? 
perhaps here on IBM-MAIN?) on the naming convention they used at SCE to 
keep it all straight. The upper nybble indicates whether a guzzinta or a 
guzzoutta, the next two nybbles represent the LPAR number, and the last 
nybble is the device number 0-F. Having this naming convention makes it 
trivially easy to know which LPARs the control units and devices should 
be connected to since the LPAR number is part of the device number.


We have only six LPARs (1, 2, 3, 4, 5 & 8), so it doesn't look too bad. 
Clearly, if you have 85 LPARs on the box it will take longer to define 
them, but still be just as easy to get it right.


--Device-- --#--- Control Unit Numbers + 
Number   Type +    CSS OS 1--- 2--- 3--- 4--- 5--- 6--- 7--- 8---
4010,16  FCTC  1   2  4010       
4020,16  FCTC  1   2  4020       
4030,16  FCTC  1   2  4030       
4040,16  FCTC  1   2  4040       
4050,16  FCTC  1   2  4050       
4080,16  FCTC  1   2  4080       
5010,16  FCTC  1   2  5010       
5020,16  FCTC  1   2  5020       
5030,16  FCTC  1   2  5030       
5040,16  FCTC  1   2  5040       
5050,16  FCTC  1   2  5050       
5080,16  FCTC  1   2  5080       

The only real drawback I can see to using CTCs like this is the "chewing 
up" of device numbers in environments with a shortage of them.



--
Phoenix Software International
Edward E. Jaffe
831 Parkview Drive North
El Segundo, CA 90245
https://www.phoenixsoftware.com/



This e-mail message, including any attachments, appended messages and the
information contained therein, is for the sole use of the intended
recipient(s). If you are not an intended recipient or have otherwise
received this email message in error, any use, dissemination, distribution,
review, storage or copying of this e-mail message and the information
contained therein is strictly prohibited. If you are not an intended
recipient, please contact the sender by reply e-mail and destroy all copies
of this email message and do not otherwise utilize or retain this email
message or any or all of the information contained therein. Although this
email message and any attachments or appended messages are believed to be
free of any virus or other defect that might affect any computer system into
which it is received and opened, it is the responsibility of the recipient
to ensure that it is virus free and no responsibility is accepted by the
sender for any loss or damage arising in any way from its opening or use.

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

Subject: To share or not to share DASD

[Don Parrott]

Gord,



We created a DASD only SYSPLEX about 3(?) years ago on a z/14 primarily to 
facilitate PDSE sharing between the PROD and DEVL lpars.   I would have rather 
had a coupling facility for a full sysplex, but we did not have one.There 
was a ton of work to setup the CTC pairs between the three lpars, the final one 
being our maintenance lpar.   GRS will have to be reviewed carefully.We 
have had zero issues since implementation.   Feel free to write me directly for 
specific questions.   d...@clemson.edu<mailto:d...@clemson.edu>



Don



> -Original Message-

> From: IBM Mainframe Discussion List 
> mailto:IBM-MAIN@LISTSERV.UA.EDU>> On

> Behalf Of Gord Neill

> Sent: Thursday, November 24, 2022 12:55 PM

> To: IBM-MAIN@LISTSERV.UA.EDU<mailto:IBM-MAIN@LISTSERV.UA.EDU>

> Subject: To share or not to share DASD

>

> [EXTERNAL EMAIL]

>

> 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

>

>

>

>


Don Parrott

zSeries Server Technical Support Team
Clemson Computing and Information Technology
Clemson University



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