Morning Skip- That was my post. I was asking what objectives were trying to be accomplished. It should have been Business Objectives. My thoughts were along your same lines. In particular, most sites NEED to segregate Data according to Prod vs. non-Prod. Your single-console is a good reason; although there are automation tools that could do the same thing (I'm not going to mention specific products). >From an application point of view, Sysplex is generally an Availability objective. While GRS Star and Extended Catalogues are a good by-product, I would not think the cost of creating a SYsplex is sufficient to enable those types of functionality. As I said, the mechanics of setting up, or merging systems into a Sysplex is fairly straight forward, and well documented; but I still say you need to have those business objectives bought into by management. There is overhead involved with Sysplex- small amount for basic, much larger amount for Parallel. I guess it was mostly curiosity on my part about need; most folks on this list can point to the mechanical pubs, and offer tips to succeed. Sometime less is more... Happy to discuss further.
zNorman -----Original Message----- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Skip Robinson Sent: Sunday, September 15, 2013 7:47 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Sysplex newbie The performance advantages of GRS star over ring are *greater* than IBM's official recommendations even for a minimal configuration. However, the decision to go parallel is not cost free, requiring memory allocation in addition to CPU resources. We have a set of system images whose sole purpose in life is to mirror DASD via XRC. They live on a single CEC. We chose from the beginning to go with basic (CTC-only) sysplex for one reason: consolidated console. With a single screen we can manage all of these systems. Basic sysplex is essentially free if you have the channel connectivity required. Like several other posters, I advise against over-merging test/development and production for one major reason: SAF. Every shop I've been in wants to enforce different security rules for production (more stringent) and test/development (less so). You cannot maintain different rules unless you have different RACF (or equivalent) data bases. Someone asked about objectives for this project. The answer came in technical terms. I would ask about business objectives. What are the business goals for sysplex as opposed to traditional shared DASD? . . JO.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 626-302-7535 Office 323-715-0595 Mobile jo.skip.robin...@sce.com From: "Staller, Allan" <allan.stal...@kbmg.com> To: IBM-MAIN@LISTSERV.UA.EDU, Date: 09/15/2013 07:10 AM Subject: Re: Sysplex newbie Sent by: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> There is , if no CF is (or planned to be) availaible. <snip> On Fri, 13 Sep 2013 20:10:05 +0000, Staller, Allan wrote: >FICON CTC's are currently supported. IIRC PTF's are available for zOS 1.12 and up.. You may be thinking of the FICON support for (non-XCF) GRS ring. FICON CTC for base sysplex has been supported "forever" - and is a no-brainer IMHO. Absolutely no sense in going (non-XCF) GRS ring if installing new these days. </snip> ---------------------------------------------------------------------- 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
