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
