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? 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
