CIS <=> CICS, sorry about the typo > -----Original Message----- > From: IBM Mainframe Discussion List [mailto:[email protected]] On > Behalf Of Gibney, Dave > Sent: Sunday, August 09, 2009 2:40 PM > To: [email protected] > Subject: Re: DASD: to share or not to share > > > -----Original Message----- > > From: IBM Mainframe Discussion List [mailto:[email protected]] On > > Behalf Of Frank Swarbrick > > Sent: Sunday, August 09, 2009 12:57 PM > > To: [email protected] > > Subject: Re: DASD: to share or not to share > > > > I believe you! > > > > Can I restate as follows? > > If we do not have a sysplex we should not be sharing PDSE datasets > between > > LPARs because an update to the PDSE in one LPAR is not guaranteed to > be > > seen immediately (or ever?) by another LPAR. (Read only PDSEs are OK > > because they are not updated.) > > > > I assume we are still fine with sharing regular PDS datasets between > LPARs > > without a sysplex? What about other types, such as regular sequential > > datasets and VSAM datasets? Having a non-sysplex are we OK here? > > 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:[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
---------------------------------------------------------------------- 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
