Yes, you can do GRS-RING using XCF communications without a CF, which would be a basic Sysplex. If you had a CF you would use GRS-STAR, which would use XES, and thus be a Parallel Sysplex. Of course, I am running a Parallel Sysplex, and it still didn't cost any additional money.
>>> "Gibney, Dave" <[email protected]> 8/10/2009 2:38 PM >>> I was still thinking CF Sysplex. I expect that I might, someday be able to do GRS with CTC connections. I don't yet understand Mark's implication that I can do XCF without a CF Lpar or two. If that's what he is really implying :) It's been a fun discussion, but today, my bottom line is to get my 1.7 to 1.9 finished before 1.9 is the oldest supported level :) My schedule is currently as soon after our begin of semester freeze is over on September 27. I expect 1.11 will be GA or close then :) Dave Gibney Information Technology Services Washington State University > -----Original Message----- > From: IBM Mainframe Discussion List [mailto:[email protected]] On > Behalf Of Scott Rowe > Sent: Monday, August 10, 2009 6:53 AM > To: [email protected] > Subject: Re: DASD: to share or not to share > > As the only Sysprog here (real or otherwise), I understand your time > concerns. However, in my situation I decided that the benefits > outweighed the cost (in time). I find that many of the features of > SYSPLEX can save me quite a bit of time (once it is set up). Just the > simplicity of having all DASD online to all systems can be a benefit. > Of course, YMMV, but I think many small shops decide against SYSLEX > without ever considering the benefits. > > I am curious why you still put a $ next to SYSPLEX? > > >>> "Gibney, Dave" <[email protected]> 8/9/2009 5:39 PM >>> > VSAM (and all SMS datasets) can't exist without being cataloged. Shared > Catalogs are not "safe" without integrity protection. Integrity > protection takes MIM ($) or Sysplex ($) and both require time to > configure and maintain. As the only real z/OS Sysprog here, I'm hard > pressed to keep up as it is, so it's unlikely I'll ever plex and I know > we'll never buy MIM. > > I should have been more specific. I only share a limited set of non-SMS > volumes and I do not put VSAM on them. Our CIS guy uses his shared > volumes for some VSAM, but the data is not really shared as the > Catalogs > are not shared. > > I don't share any SMS pools. If they want Production data for testing, > they have to make a copy (generally using a couple of shared volumes > designated for that specific purpose). Most of the shared datasets are > JCL, PROC, LOAD, ISPxLIB, PARMLIB(s), etc. > > I am fully aware of the risks I'm taking (I think so anyway). > > What I need to do to remain employed here until retirement is learn > then > convince the Powers that Be, that zLinux is the best platform for the > Oracle based ERP that's almost inevitable. > > > > > Thanks for you patience in educating this lowly applications > developer. > > > > Frank > > -- > > > > Frank Swarbrick > > Applications Architect - Mainframe Applications Development > > FirstBank Data Corporation > > Lakewood, CO USA > > P: 303-235-1403 > > F: 303-235-2075 > > > > > > On 8/9/2009 at 11:45 AM, in message > > <listserv%[email protected]>, Mark Zelden > > <[email protected]> wrote: > > > If children play with fire, they will eventually get burned! > > > > > > > > > On Sat, 8 Aug 2009 22:42:04 -0600, Frank Swarbrick > > > <[email protected]> wrote: > > > > > >>That is exactly what I did. Well, "as quickly as I could type", in > any > > case. > > >>We have PDSESHARING(NORMAL) in our IGDSMSxx file, for whatever that > > might > > > be worth. > > >> > > > > > > It's worth nothing in regards to sharing PDSE across sysplex > boundaries > > for > > > anything but READ ONLY functions. > > > > > >>On 8/8/2009 at 1:31 AM, in message > > >><[email protected]>, > > "Gibney, > > >>Dave" <[email protected]> wrote: > > >>> Actually I was speculating about the ability to "refresh" in > memory > > >>> knowledge of the PDSE(s) in the other LPAR(s). > > > > > > There is no command or facility to do that. There is the sledge > hammer > > > approach of IPLing. :-) Well... it may not be all that bad - > more > > below. > > > > > > > > >>> What you describe is not > > >>> guaranteed. > > >>> Try 1. Run existing copy of the program in LPAR-P. 2. Quickly > update > > >>> it from LPAR-other. 3. Quickly try in LPAR-P. I don't believe you > will > > >>> always get the new version. > > > > > > Apparently he did. But why? (more below) > > > > > >>> > > >>>> -----Original Message----- > > >>>> From: IBM Mainframe Discussion List [mailto:IBM- > [email protected]] > On > > >>>> Behalf Of Frank Swarbrick > > >>>> Sent: Friday, August 07, 2009 1:34 PM > > >>>> To: [email protected] > > >>>> Subject: Re: DASD: to share or not to share > > >>>> > > >>>> So for example, if our change control process for applications > runs > > in > > >>> DEV > > >>>> (which is how we have it in VSE) we should be able to update our > > >>>> production application loadlib PDSE from DEV exclusively and > this > > will > > >>> not > > >>>> be a problem, even without a Sysplex? I am curious as to where > I > > find > > >>>> this PDSE address space refresh command, and if it's really > needed. > > I > > >>>> just compiled a program in to a PDSE in DEV and ran it in PROD > and it > > >>> ran > > >>>> the new version just fine. Did it twice just to make sure. No > > >>> problem > > >>>> either time. > > >>>> > > > > > > This probably worked for 2 reasons: > > > > > > 1) Nothing else had the target loadlib allocated and / or opened. > > > > > > 2) PDSE(1)_BUFFER_BEYOND_CLOSE was not set to YES. > > > > > > Try the same test again with the target (output) PDSE loadlib that > is in > > > use by a long running address space, say... a CICS region. Or how > about > > > a library that happens to be in LLA or the LNKLST. > > > > > > Changes to PDSE data sets in a sysplex are communicated via XCF. > Which > > > means if you don't have a sysplex, you are S.O.L. when it comes to > > sharing > > > PDSEs that need to have changes made (update). > > > > > > I mentioned the sledge hammer approach of IPLing above. The same > goal > > > can probably be achieved (reading a "fresh copy" of the PDSE) if > you > can > > > make sure no address spaces are using the PDSE and you aren't using > the > > > PDSE(1)_BUFFER_BEYOND_CLOSE=YES option. But that could be a > > > really difficult task in a production environment depending on the > > library. > > > > > > Mark > > > -- > > > Mark Zelden > > > Sr. Software and Systems Architect - z/OS Team Lead > > > Zurich North America / Farmers Insurance Group - ZFUS G-ITO > > > mailto:[email protected] > > > z/OS Systems Programming expert at > > http://expertanswercenter.techtarget.com/ > > > Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html > > > > > > > ---------------------------------------------------------------------- > > > For IBM-MAIN subscribe / signoff / archive access instructions, > > > send email to [email protected] with the message: GET IBM-MAIN > INFO > > > Search the archives at http://bama.ua.edu/archives/ibm-main.html > > > > >>> > > > > The information contained in this electronic communication and any > > document attached hereto or transmitted herewith is confidential and > > intended for the exclusive use of the individual or entity named > above. > > If the reader of this message is not the intended recipient or the > > employee or agent responsible for delivering it to the intended > recipient, > > you are hereby notified that any examination, use, dissemination, > > distribution or copying of this communication or any part thereof is > > strictly prohibited. If you have received this communication in > error, > > please immediately notify the sender by reply e-mail and destroy this > > communication. Thank you. > > > > --------------------------------------------------------------------- > - > > For IBM-MAIN subscribe / signoff / archive access instructions, > > send email to [email protected] with the message: GET IBM-MAIN > INFO > > Search the archives at http://bama.ua.edu/archives/ibm-main.html > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to [email protected] with the message: GET IBM-MAIN INFO > Search the archives at http://bama.ua.edu/archives/ibm-main.html > > > > CONFIDENTIALITY/EMAIL NOTICE: The material in this transmission > contains confidential and privileged information intended only for the > addressee. If you are not the intended recipient, please be advised > that you have received this material in error and that any forwarding, > copying, printing, distribution, use or disclosure of the material is > strictly prohibited. If you have received this material in error, > please (i) do not read it, (ii) reply to the sender that you received > the message in error, and (iii) erase or destroy the material. Emails > are not secure and can be intercepted, amended, lost or destroyed, or > contain viruses. You are deemed to have accepted these risks if you > communicate with us by email. Thank you. > > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to [email protected] with the message: GET IBM-MAIN INFO > Search the archives at http://bama.ua.edu/archives/ibm-main.html ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html CONFIDENTIALITY/EMAIL NOTICE: The material in this transmission contains confidential and privileged information intended only for the addressee. If you are not the intended recipient, please be advised that you have received this material in error and that any forwarding, copying, printing, distribution, use or disclosure of the material is strictly prohibited. If you have received this material in error, please (i) do not read it, (ii) reply to the sender that you received the message in error, and (iii) erase or destroy the material. Emails are not secure and can be intercepted, amended, lost or destroyed, or contain viruses. You are deemed to have accepted these risks if you communicate with us by email. Thank you. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
