Re: UCB PINNED by CAS, Why?
I see that IBM *still* hasn't gotten this fixed (but then, I did not expect them to). It was in November 2006 that we had an unplanned installation-wide IPL after a dynamic IODF change due to the fact that CAS doesn't care if you tell it that a catalog is gone, it simply reopens that catalog on any generic search (no matter that you've taken it away) and abends every time *any* catalog request is made because they use - sight unseen - the UCB pointer out of the CAXWA. I had a bloody row back then with Mark Thomen about it. They had never heard of the ENF signal that dynamic activate uses to tell the world 'this volume is going away' And I did not accept the excuse 'you don't have ptf xyz on' (especially when xyz didn't have anything to do with the abends). The outcome of that encounter was OA18898 - closed REQ - plus a marketing requirement. The final fix may or may not come in 1.12. Just be thankful the catalog component pins its UCBs these days (they did not do it when we had the outage)! But thanks for letting me point this out again. Barbara -- 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
Re: USS misuse
>... but I also remembered the Resolver address space and INET/CINET. Yes, and my abendb78 in resolver code (and subsequent 0C4 in BPXsomething) will both get fixed in BPX code:-) >Regarding your problems with your TCPTNx address spaces: I hope this is all >to do with TN3270 address spaces and nothing to do with otelnetd. It may be >my total unfamiliarity with otelnetd in practice that makes this a stupid >question. However you always refer to TELNET and not TN3270 - or TN3270E. I meant TN3270 asids. That's why I warned that I haven't got a clue about those address spaces. Actually, the B78 in resolver was caused by a wrong INETD restart and exposed when a collegue used telnet to get into OMVS. (In the ETR I added VT100 - my IPÜ guy told me so:-)) >I see you had difficulty getting the address spaces to disappear. I just checked the sched members in use. Though none of the IP address spaces are set explicitly in the PPT, they do make themselves an entry in the PPT (shown by SHOWZOS): PGMNAME(EZBTCPIP)KEY(6) Nocancel Noswap Priv SYST Spref Lpref - Default PGMNAME(EZBREINI)KEY(6) Nocancel Noswap Priv SYST - Default PGMNAME(EZBTNINI)KEY(6) Nocancel Noswap Priv SYST - Default The problem was not really that I could not cancel them (I did issue the force arm instead). The problem was that they did not terminate in reaction to *any* shutdown command - no stop, no force arm. FORCE executes in master and bypasses all tcb resource managers that may have wanted to run but could not because the needed OMVS service wasn't available anymore (my guess). That's what I consider a BUG (and not WAD), as IBM tries to tell me. Best regards, Barbara ps: See? No USS in my post! :-) -- 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
Re: Telnet, was: Re: USS misuse
>Yes. This sounds like APARable behavior. Unless they designed >the server to purposefully hang. :-) Broken as designed? >I'm sort of surprised that anything in TCP/IP worked after a restart >of OMVS, and I'm not surprised that different parts failed (or not) >in different ways. There must have been timing dependant failures >all over the place. What I expect when I terminate OMVS in full flight is that every address space that cannot survive without these BPX services also terminates. There were three or four exceptions to it: 1. One of the DB2 asids said immediately that it will block shutdown. *That* address space I was able to terminate successfully using normal shutdown commands from automation. Then I re-issued the F OMVS,shutdown command. 2./3. At this point two of the three TN3270 asids (which I sloppily call 'telnet address spaces', mostly for lack of knowledge in the TCPIP area) said that *they* are blocking OMVS shutdown. I attempted to use automation to get them to terminate. This failed miserably as they apparently need *something* from OMVS while terminating which did not work anymore. I had to force them down. 4. The third TN3270 asid gave an indication that it terminates, but it didn't. It also did not block shutdown like the other two did. OMVS simply took down everything else, I issued the F OMVS,restart command and then (via automation) restarted everything that had terminated during the OMVS shutdown. That third TN3270 appeared unaffected for about a week. *Then* a colleague needed those services and it turned out that basically *nothing* worked in there. Abend202 posting an ECB that had gone eons earlier when that address space was shut down. (At least it terminated without force.) >Does IBM claim that TCP/IP and its associated bits and pieces can >survive the loss and restart of OMVS? If so, they should make it >work. No, IBM doesn't claim that. If any claim is made then that the address spaces relying on OMVS will terminate when OMVS goes away. I seem to remember a post from Jim Mulder from years ago that lack of recovery in OMVS exploiters was what prohibited IBM from making OMVS restartable. Given that the shutdown/restart command is now possible, *I* as a customer expect the IBM exploiters of BPX services to have recovery in place that detects OMVS going away (there is a kind of exit that gets called when OMVS receives the shutdown command. I am assuming that is what DB2 uses to 'block' shutdown). And I expect every address space that cannot live without OMVS to go away, too. In my opinion, it is definitely incorrect (and aparable) when TN3270 asid a) sleeps through shutdown but doesn't work afterwards) b) cannot be terminated cleanly anymore. We did not do the OMVS shutdown excercise just for fun, we did have a semi- production problem where we weren't sure if an IPL was required. Given that most of our work is IMS, an OMVS restart would have been preferable to a during-the-day-IPL, with less downtime. And as time was at a premium, I much rather 'fix' automation stati after an OMVS restart than wait for orderly shutdown. Some of those OMVS exploiters (WAS comes to mind) take about 20 minutes to come down. After the OMVS restart, with the exception of that one TN3270 *everything* worked again. So that one TN3270 must behave like the others - either 'block' shutdown or come down cleanly, too. (Actually, they all MUST respond to a shutdown command, which they did not.) I only remember one address space living through the restart, and that was Automation Netview. It complained, withdrew its feet from OMVS, but did not terminate. Regards, Barbara -- 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
"SE" on *master*; was: Re: How to eliminate the igd17223i message from the syslog under sdsf.
Peter, >Well, that's something every application person here knows and uses >every day: I think you missed the significance of doing the SE command in front of the *master* address space! Exactly what type of JCL are you expecting in *master* that you could re-submit? :-) I cannot even say that asid 1 is started sub=mstr. Sub=MSTR address spaces by default do not have anything JES can look into *unless* they request connection to JES later. So *master* does that for the syslog task, as well as a task in automation Netview (also started sub=mstr) for the AOFLOG. Regards, Barbara Nitz -- 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
Re: DASD: to share or not to share
> -Original Message- > From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On > Behalf Of Mark Zelden > Sent: Sunday, August 09, 2009 8:17 PM > To: IBM-MAIN@bama.ua.edu > Subject: Re: DASD: to share or not to share > > On Sun, 9 Aug 2009 14:39:32 -0700, Gibney, Dave wrote: > > > > >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. > > > > > GRS is free and it doesn't require a sysplex. Or you can use a basic > sysplex. Yes, there is some configuration steps, but once set up it > isn't likely to eat into your time. True, and last time we revamped the IODF I had the required CTC(s) added. That was over a year ago when we brought in the z9-BC and is the last time I had a chance to take a baby step that direction. Also, on this list, I'm led to understand that our four would LPARs push or exceed GRS ring performance. > > 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 -- 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
Re: DASD: to share or not to share
On Sun, 9 Aug 2009 14:39:32 -0700, Gibney, Dave wrote: > >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. > GRS is free and it doesn't require a sysplex. Or you can use a basic sysplex. Yes, there is some configuration steps, but once set up it isn't likely to eat into your time. 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
C.D. Keltie is away.
I will be out of the office starting 10/08/2009 and will not return until 17/08/2009. -- 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
Infoprint set up in zos
2 Question: 1) For CICS printing, is it no change on current VTAM printer setup? 2) No application programs needed to change? 3) Implement IP Printway option will enable all printouts from normal PC printers? Thanks, Philip -- 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
Re: CSC Comtec's HMO software (Pick) on z/OS SYSPLEX
I think I over emphasized the Linux factor. The real question is: "Does anyone know of an installation that is running CSC Comtec's HMO software (Pick Data Base) on a z/OS SYSPLEX?" -- 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
Was RE: SNA, the acronym. Is SNA really an acronym or an initialism ?
You will find some dictionary definitions (example Wikipedia) that would define SNA and IBM as examples of an initialism, not an acronym. KISS and CORBA are examples that most (all?) definitions agree to classify as acronyms because they spell out a word. CICS could probably be one or the other depending on your age and which side of the pond you inhabit. Cheers, Brendan > Date: Mon, 10 Aug 2009 01:14:09 + > From: john_w_gilm...@msn.com > Subject: SNA, the acronym > To: IBM-MAIN@bama.ua.edu > > Context is all. This acronym, unsurprisingly, is overloaded. > > > > Sna is the name of a marine homologue of the Drosophila snail. > > > > SNA is an acronym for Sympathetic Nerve Activity. > > > > SNA is an acronym for System of National Accounts. > > > > Etc., etc. > > > > Here, however, it is likely, all but certain, to refer to IBM's Systems > Network Architecture. > > > > Perhaps we should try to move on from wide-eyed wonder at the notion, novel > to schoolboys, that acronyms are context-sensitive and ambiguous. > > > John Gilmore Ashland, MA 01721-1817 USA > > > > _ > Express your personality in color! Preview and select themes for Hotmail®. > http://www.windowslive-hotmail.com/LearnMore/personalize.aspx?ocid=PID23391::T:WLMTAGL:ON:WL:en-US:WM_HYGN_express:082009 > -- > 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 _ Get free photo software from Windows Live http://www.windowslive.com/online/photos?ocid=PID23393::T:WLMTAGL:ON:WL:en-US:SI_PH_software:082009 -- 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
Re: SNA, the acronym
>Context is all. This acronym, unsurprisingly, is overloaded. Do we really need to open up another (off-topic) thread? I can pick many acronyms that are overloaded: SMS ISAM USS NSA etc. Why burden us with them all. I mean, can't we waste each other's time with other off-topics? - Too busy driving to stop for gas! -- 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
SNA, the acronym
Context is all. This acronym, unsurprisingly, is overloaded. Sna is the name of a marine homologue of the Drosophila snail. SNA is an acronym for Sympathetic Nerve Activity. SNA is an acronym for System of National Accounts. Etc., etc. Here, however, it is likely, all but certain, to refer to IBM's Systems Network Architecture. Perhaps we should try to move on from wide-eyed wonder at the notion, novel to schoolboys, that acronyms are context-sensitive and ambiguous. John Gilmore Ashland, MA 01721-1817 USA _ Express your personality in color! Preview and select themes for Hotmail®. http://www.windowslive-hotmail.com/LearnMore/personalize.aspx?ocid=PID23391::T:WLMTAGL:ON:WL:en-US:WM_HYGN_express:082009 -- 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
Re: VTAM security issue
Paul Gilmartin wrote: Now I'm confused. What does the initialism "SNA" stand for? It's the Airport code for John Wayne Airport in Orange County. -- Edward E Jaffe Phoenix Software International, Inc 5200 W Century Blvd, Suite 800 Los Angeles, CA 90045 310-338-0400 x318 edja...@phoenixsoftware.com http://www.phoenixsoftware.com/ -- 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
Re: DASD: to share or not to share
CIS <=> CICS, sorry about the typo > -Original Message- > From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On > Behalf Of Gibney, Dave > Sent: Sunday, August 09, 2009 2:40 PM > To: IBM-MAIN@bama.ua.edu > Subject: Re: DASD: to share or not to share > > > -Original Message- > > From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On > > Behalf Of Frank Swarbrick > > Sent: Sunday, August 09, 2009 12:57 PM > > To: IBM-MAIN@bama.ua.edu > > 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 > > , Mark Zelden > > wrote: > > > If children play with fire, they will eventually get burned! > > > > > > > > > On Sat, 8 Aug 2009 22:42:04 -0600, Frank Swarbrick > > > 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 > > >>, > > "Gibney, > > >>Dave" 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 (out
Re: VTAM security issue
Isn't the A Architecture? And the S Synchronous :) > -Original Message- > From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On > Behalf Of Patrick O'Keefe > Sent: Sunday, August 09, 2009 2:43 PM > To: IBM-MAIN@bama.ua.edu > Subject: Re: VTAM security issue > > On Sun, 9 Aug 2009 16:03:33 -0500, Paul Gilmartin > wrote: > > >On Sun, 9 Aug 2009 11:57:15 -0400, Anne & Lynn Wheeler wrote: > >> > >>possibly SNA organization viewed it as competition (even tho SNA had > >>nothing to do with networking). > >> > >Now I'm confused. What does the initialism "SNA" stand > >for? > > > >Or, while this list is focused on initialism pedantry, > >is it possible that there's another "SNA" than the one > >I found at the top of a Google search? > >... > > Well, the N is "Network", not "Networking", but I don't think that > clarifies anything. Lynn apparently has some very specific defibition > of "Networking" in mind. His comment may be accurate (His comments > usually are.) but I'm not sure what that comment really was. > > SNA does not have a universal addressing scheme and IP does. > Perhaps that was the point. But SNI provided that in sort of the > same way that NATing allows interconnection of 2 IP networks that > use private IP addresses. > > SNA does not provide a universal name space for resources, but > neither does IP. The Domain Name space used by IP hosts is > not provided by, or dependent on IP. > > Pat O'Keefe > > -- > 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
Re: VTAM security issue
On Sun, 9 Aug 2009 16:03:33 -0500, Paul Gilmartin wrote: >On Sun, 9 Aug 2009 11:57:15 -0400, Anne & Lynn Wheeler wrote: >> >>possibly SNA organization viewed it as competition (even tho SNA had >>nothing to do with networking). >> >Now I'm confused. What does the initialism "SNA" stand >for? > >Or, while this list is focused on initialism pedantry, >is it possible that there's another "SNA" than the one >I found at the top of a Google search? >... Well, the N is "Network", not "Networking", but I don't think that clarifies anything. Lynn apparently has some very specific defibition of "Networking" in mind. His comment may be accurate (His comments usually are.) but I'm not sure what that comment really was. SNA does not have a universal addressing scheme and IP does. Perhaps that was the point. But SNI provided that in sort of the same way that NATing allows interconnection of 2 IP networks that use private IP addresses. SNA does not provide a universal name space for resources, but neither does IP. The Domain Name space used by IP hosts is not provided by, or dependent on IP. Pat O'Keefe -- 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
Re: DASD: to share or not to share
> -Original Message- > From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On > Behalf Of Frank Swarbrick > Sent: Sunday, August 09, 2009 12:57 PM > To: IBM-MAIN@bama.ua.edu > 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 > , Mark Zelden > wrote: > > If children play with fire, they will eventually get burned! > > > > > > On Sat, 8 Aug 2009 22:42:04 -0600, Frank Swarbrick > > 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 > >>, > "Gibney, > >>Dave" 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 s
Re: VTAM security issue
On Sun, 9 Aug 2009 11:57:15 -0400, Anne & Lynn Wheeler wrote: > >possibly SNA organization viewed it as competition (even tho SNA had >nothing to do with networking). > Now I'm confused. What does the initialism "SNA" stand for? Or, while this list is focused on initialism pedantry, is it possible that there's another "SNA" than the one I found at the top of a Google search? --gil -- 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
Re: DASD: to share or not to share
On Sun, 9 Aug 2009 13:56:53 -0600, Frank Swarbrick wrote: >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.) Worse! If the library was open / in use on the other LPAR, you will likely get an 0F4 abend at the next open or soon after and not be able to open / read the library at all after the update has been made. > >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? > It can be done with many caveats. I jumped in the middle of this thread but I'm sure some of it has been discussed already. Reserve will protect the VTOC from corruption, but not individual data sets.VSAM has some of its own protection mechanisms depending on the share options. The bottom line is you need an integrity manager like GRS or MII (MIM) to propegate ENQs to the other system(s) for safe sharing. But PDSE and HFS are a special case and can't be shared outside the sysplex (except read only) regardless of an integrity manager like GRS or MIM/MII. Oh, BTW, you won't get any RESERVE protection for SYSVTOC, SYSZVVDS or others if you don't gen the DASD as shared to begin with. 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
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? 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 , Mark Zelden wrote: > If children play with fire, they will eventually get burned! > > > On Sat, 8 Aug 2009 22:42:04 -0600, Frank Swarbrick > 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 >>, "Gibney, >>Dave" 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. --
Re: DASD: to share or not to share
If children play with fire, they will eventually get burned! On Sat, 8 Aug 2009 22:42:04 -0600, Frank Swarbrick 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 >, "Gibney, >Dave" 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
Re: RMM Retention WHILECATLG
Dennis, In rmm it is the retention date that can have the
value 'WHILECATLG'. The retention date is set via VRSEL processing by
matching to a VRS. For a data set, one way to achieve what you want is:
1. Create a WHILECATALOG VRS
RMM AS DSNAME('CATALOG') WHILECATALOG
2. Assign it to each data set you want to be catalog controlled
RMM CD DSNAME(dsname) VOLUME(volser) FSEQ(seqnum) MANAGEMENTCLASS
(CATALOG)
3. run EDGHSKP VRSEL.
Mike Wood RMM Development
On Tue, 4 Aug 2009 13:00:39 -0700, Longnecker, Dennis
wrote:
>Is there a way to mass change a bunch of datasets and/or volsers to have
the WHILECATLG expiration date?
>
>RMM From ispf panels =RMM.3.1.3 only gives me a 4 position retention
period.
>
>I have about 30 I need to change.
>
>--
--
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
Re: VTAM security issue
chrisma...@belgacom.net (Chris Mason) writes: > There is no universal SNA network - as some in IBM imagined could be > created in the early '80s - and so the access to these supposedly > vulnerable VTAM systems is going to be via the universal IP > network.[1] Thus one of the protocols whereby the IP network is > suborned to serve as a logical link in the SNA network will be used. SNA isn't a networking infrastructure, it is large closed dumb terminal control infrastructure. It is even more restrictive than OSI ... which also wasn't an open infrastructure. SNA lacked both a network layer as well as a internetworking layer ... while OSI had a network layer ... but also lacked an internetworking layer. The internetworking layer (found in IP) was necessary for creating an open infrastructure (as a layer that would internetwork networks). The "universal" SNA was on par with government GOSIP mandates that the internet was to eliminated and replaced with OSI (which never happened, I've frequently asserted because OSI lacked internetworking layer ... even tho it was slightly better than SNA by actually having a network layer). The closest (with a networking layer) that might be claimed for SNA might be APPN ... but the original APPN announcement was vetoed by the SNA organizaton ... after 6-8 weeks it was finally announced, but the announcement letter was carefully rewritten to avoid implying any relationship between APPN and SNA. We would periodically hassle the person responsible for APPN to stop playing around with internal stuff and come work on real networking (APPN specification was AWP164). Back in the early days of SNA ... my wife was co-author of "peer-to-peer" networking (only when SNA had co-opted the term "networking" ... was it necessary to qualify specification "peer-to-peer"). This was (internal specification) AWP39 ... and possibly SNA organization viewed it as competition (even tho SNA had nothing to do with networking). Later when she had been con'ed into going to POK to be in charge of loosely-coupled architecture ... she had lots of battles with the SNA organization. Eventually there was a (temporary) truce where she was allowed to do anything she wanted within the perimeter of the datacenter walls ... but SNA had to be used anytime the datacenter walls were crossed. While in POK, she created "peer-coupled" shared data architecture ... some past posts http://www.garlic.com/~lynn/submain.html#shareddata which, except for IMS hot-standby, saw very little uptake until sysplex. Somewhat related recent post mentioning working on PU4/PU5 emulation product that carried RUs in real networking environment (but converted at boundaries when talking to real pu5/vtam host) http://www.garlic.com/~lynn/2009k.html#70 An inComplete History Of Mainframe Computing above references this decade old post ... which includes part of project presentation that I gave at fall86 SNA architecture review board meeting in Raleigh http://www.garlic.com/~lynn/99.html#67 as an aside ... the internal network ... which wasn't SNA ... was larger than the arpanet/internet from just about the beginning until possibly late-85 or early-86 http://www.garlic.com/~lynn/subnetwork.html#internalnet post mentioning the 1000th node (on the internal network) in 1983 (83 was when the arpanet/internet was passing 255 hosts) http://www.garlic.com/~lynn/2006k.html#8 above also lists internal datacenters/locations having one or more new/added networking nodes during 1983. -- 40+yrs virtualization experience (since Jan68), online at home since Mar1970 -- 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
Re: VTAM security issue
JM > Right now I understand there are 20+ ways which VTAM/SNA systems
have been compromised.
HM > Please give us some details on the compromised VTAM/SNA systems.
Hal Merritt - and perhaps many others including myself - are still waiting for
Jim Marshall's reply.
I intended to reply to Jim Marshall's post at the time but thought I'd wait
until
the description of these "20+ ways" spilled into our inboxes. I waited in vain
and, unfortunately, I forgot.
Since I have been reminded by another burst of FUD regarding VTAM and SNA,
I may as well now get the intended reply out now.
It's interesting to note that Jim Marshall's reply to the original post
appeared
after - by three days - the OP, Itschak Mugzach, had acknowledged that the
answer was available from native VTAM definitions.
JM > I appreciate the response from my learned colleague and he is correct
about SNA Security being available.
This refers to a rebuttal (Mon, 19 Jan 2009 07:41:17 -0600) of a response
(Sat, 17 Jan 2009 20:06:38 -0600) to the original thread (Tue, 13 Jan 2009
21:33:35 +0200) where SNA firewalls were promoted. Incidentally more that
simply the availability of encryption was covered.
JM > For one it is hardly every used and its encryption has not kept up with
all
the improvements.
So it seems other products are sold on the basis that customers are ignorant
of a VTAM facility which offers the following (from the APPL statement):
ENCRTYPE
ENCRTYPE=DES ENCRTYPE=TDES24
Specifies the minimum type of encryption that VTAM should use on behalf of
the application when performing session level encryption.
ENCRTYPE=DES
Specifies that VTAM must use a minimum of DES encryption with an 8byte
key when performing session level encryption. This is the default.
ENCRTYPE=TDES24
Specifies that VTAM must use a minimum of Triple_DES encryption with a 24
byte key when performing session level encryption.
I believe Jim Marshall is just trying to dismiss a fact inconvenient for the
product he is promoting? FUD!
The VTAM encryption support looks just fine to me. Can anyone - else - find
fault with that? I have recently been involved in a project where encryption
over the IP network using - I thought - current IP products. The chatter I
heard was peppered with "triple-DES"!
JM > But I do contend, the thinking that VTAM even being secured by SNA is
insufficient.
And I "contend" otherwise! - and it's up to Jim Marshall to prove the contrary.
JM > With all the capabilities these days of anyone having a legal MVS running
system along with LU6.2 coming from almost every running UNIX system and
not to mention Windows systems as SNA Servers, ...
Pure FUD!
There is no universal SNA network - as some in IBM imagined could be created
in the early '80s - and so the access to these supposedly vulnerable VTAM
systems is going to be via the universal IP network.[1] Thus one of the
protocols whereby the IP network is suborned to serve as a logical link in the
SNA network will be used.
These protocols are DLSw, AnyNet over SNA and Enterprise Extender. We can
dismiss AnyNet over SNA since it is expected completely to be replaced by
Enterprise Extender.
DLSw seems to be source of exposures I have heard about in the past but
what I noticed when digging in just a little bit was that the exposure was in
the IP network and not the SNA network - even if the so-called journalist's
headline was something on the lines of "SNA Security Exposure!". Probably
there was a failure in the IP firewall definitions, assuming there was an IP
firewall at all.
Exceptions to the above are the following:
1. TELNET and TN3270 can be controlled using an IP firewall. The same
issue/problem exists as for any TELNET server.
2. "LU type 6.2" access in a manner (similar to TELNET in support of 3270 data
streams) - about which I know very little - can surely also be controlled with
IP firewalls.
So what good is having a system that can behave as anybody's VTAM ("a
legal MVS running system") or a "distributed platform" running TELNET/TN3270
or "LU type 6.2" if you can't connect it to do its "thing" (based on the TCP or
UDP port I assume) over the IP network? FUD exposed!
JM > ..., VTAM needs to be protected much more than people think.
That'll be the node where the IP protocols pass over to the SNA protocols
needs to be protected - whatever people may think - which looks very much
like IP business-as-usual: call for the (IP) firewall!
JM > Indeed how did we survive all these years without some Firewall product.
IP had yet to enter the picture - and maybe hackers hadn't yet realised their
opportunity!
JM > My thought is hardly anyone had a spare IBM 4341 in their basement to
even attempt it.
I don't really see the point here.[2]
JM > I attended a SHARE back in the 1990s and bumped into the IBMer who
maintained the Bisynchronous protocol when I discussed FAX'ing. It seems for
25 years it was stable but someone found a BUG in i
Re: Problems occured when using DFSMSdss to dump and restore DB2 data sets
Richard Pace pisze: [...] I believe the reference says you may copy DB2 data sets with DFSMSdss or with VSAM utilities that use CI processing; e.g. VSAM EXPORT CIMODE (RECORDMODE is the default and cannot be used with DB2 data sets - most DB2 data sets are linear data sets or specially formated VSAM and cannot be processed by record level VSAM services). This is incorrect. You can use i.e. IDCAMS or DSS *without* specifying CIMODE, the mode is set automatically for LDS. Every LDS, not DB2 LDS. And there is no special format of DB2 (in terms of VSAM). DB2 owned VSAM datasets can be copied using regular tools like dss or IDCAMS. It has nothing to do with DB2 access to these datasets and requirements that during "regular" copy DB2 should be shut down. My $0.02 -- Radoslaw Skorupka Lodz, Poland -- 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
Re: DASD: to share or not to share
I'm glad it worked, I still wouldn't trust it to do so. I trust sharing PDSE in static read-only mode because some folks I trust on this list who are far more knowledgeable than I assure me. I do not trust the in memory aspects of PDSE in one LPAR to notice (and so continue in future releases) update made in another LPAR without the benefit of Sysplex. If the artist, or some of the others were to give me such assurances, I might change my mind. But with OCO and the documented unsupported status of such behavior, I don't think any of them would be so willing. Your mileage may vary and other comments from Phil's disclaimer :) > -Original Message- > From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On > Behalf Of Frank Swarbrick > Sent: Saturday, August 08, 2009 9:42 PM > To: IBM-MAIN@bama.ua.edu > Subject: Re: DASD: to share or not to share > > 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. > > Frank > > On 8/8/2009 at 1:31 AM, in message > , > "Gibney, > Dave" wrote: > > Actually I was speculating about the ability to "refresh" in memory > > knowledge of the PDSE(s) in the other LPAR(s). 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. > > > >> -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. > >> > >> Frank > >> > >> On 8/7/2009 at 3:27 AM, in message > >> , > >> "Gibney, > >> Dave" wrote: > >> > I agree, but I doubt this applies to someone converting from VSE to > >> > their first z/OS LPAR(s). And, I think with "careful" change > > management, > >> > you could update even shared PDSE without sysplex. Do the update > > from > >> > only one system ever and cause that PDSE address space (can't > > remember > >> > it right off) to refresh in the other LPARs. > >> > > >> >> -Original Message- > >> >> From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] > > On > >> >> Behalf Of Bruce Hewson > >> >> Sent: Thursday, August 06, 2009 10:51 PM > >> >> To: IBM-MAIN@bama.ua.edu > >> >> Subject: Re: DASD: to share or not to share > >> >> > >> >> Hi Dave,, > >> >> > >> >> with systems that are only IPL'd every 3-5 months, YES, there will > > be > >> >> updates > >> >> to those volumes. Changes still happen, and many fixes do not > > require > >> > an > >> >> IPL > >> >> to implement, only careful change management. > >> >> > >> >> On Thu, 6 Aug 2009 14:18:15 -0700, Gibney, Dave > >> > wrote: > >> >> > >> >> >It may not be "supported", but PDSE that are only read are safe to > >> > share > >> >> >betwixt anything. And, since it's a "live" resvol, it is of course > >> > not > >> >> >subject to updates, right? > >> >> > > >> >> >Dave Gibney > >> >> >Information Technology Services > >> >> >Washington State University > >> >> > > >> >> > >> >> > >> >> Regards > >> >> Bruce Hewson > >> >> > >> >> > > -- > >> >> 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 > >> > >> >>> > >> > >> 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 communicati
