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:ibm-m...@bama.ua.edu] On > Behalf Of Scott Rowe > Sent: Monday, August 10, 2009 6:53 AM > To: IBM-MAIN@bama.ua.edu > 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" <gib...@wsu.edu> 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%200908091245525790.0...@bama.ua.edu>, Mark Zelden > > <mark.zel...@zurichna.com> wrote: > > > If children play with fire, they will eventually get burned! > > > > > > > > > On Sat, 8 Aug 2009 22:42:04 -0600, Frank Swarbrick > > > <frank.swarbr...@efirstbank.com> 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 > > >><edfbe8a9b39ed541ba3c8177c32ff0c8bc3...@exchangevs-02.ad.wsu.edu>, > > "Gibney, > > >>Dave" <gib...@wsu.edu> 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- > m...@bama.ua.edu] > On > > >>>> Behalf Of Frank Swarbrick > > >>>> Sent: Friday, August 07, 2009 1:34 PM > > >>>> To: IBM-MAIN@bama.ua.edu > > >>>> 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:mark.zel...@zurichna.com > > > 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 lists...@bama.ua.edu 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 lists...@bama.ua.edu 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 lists...@bama.ua.edu 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 lists...@bama.ua.edu 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 lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
