Re: Non-SMS-managed LOGR offload data sets
Ted MacNEIL eamacn...@yahoo.ca wrote in message news:325749814-1271266055-cardhu_decombobulator_blackberry.rim.net-2135 6707...@bda026.bisx.prod.on.blackberry... PSLC is pretty simple. Your qualifying sysplex (biggest one) has to be 50% or more of the used capacity on each box. 80% is the value I heard. HEARD? Is it documented anyhwhere? It was in 1998. We got PSLC by running SYSLOGR and Batch on the CEC. I don't know if it's more complex now. The next two companies I worked for got better pricing through WLC. - Don't forget ULC. PSCL plus ULC is still the most advantageous option for us. Kees. For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286 -- 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: Software Pricing Opportunities (WAS: Non-SMS-managed LOGR offload data sets)
Don't forget ULC. PSCL plus ULC is still the most advantageous option for us. I've forgotten what ULC is (if I ever knew). There are so many pricing options around, and if you have knowledgable negotiators, you can get a deal so many different ways. It's almost as if each shop has its own customised option. In every site I've worked at there have been opportunities to cut costs. Sometimes, you have to perform unnatural acts to get the breaks, but I've never had to 'break up' a SYSPLEX. I've received deals by putting two together, though. Also, GDPS is difficult if you have more than one PRODPLEX. In general, I've found IBM (and most ISVs) willing to cut a deal, usually because lower revenue from a customer is better than no revenue from that same customer. Sometimes, I've had to threaten to take my business elsewhere. This is most effective when there is a workalike, or something close, that is cheaper right out of the box. - 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
Re: Non-SMS-managed LOGR offload data sets
On Wed, 14 Apr 2010 17:39:53 -0500, Arthur Gutowski aguto...@ford.com wrote: In keeping with the consolidated response (if I'm not losing too much context): Mark, Yes, I recall the striping issue you had. I think we can avoid that. Yes, the allocate/delete job is what I referred to. Glad to hear that's not needed any longer. One less hurdle for our Storage team. Band-Aids can be tough to remove. In which direction did you adjust the migration threshold? First, lets rewind a little. This thread was originally discussing the issues related to LOGR in a sysplex with heterogeneous LPARs. Our sharing of LOGR volumes across SMSplexes was a requirement (although the title of this thread is non-SMS LOGR). Making our SVC dump pool shared was done at my request. The development sysplex in this environment is pretty much all static data (SAP DB2 in one LPAR, WAS in the other) and I couldn't get the storage team to implement HSM in that sysplex to manage the dumps. So I pushed them to create the single pool across SMSplex boundaries. This worked, but since the HSM migrations that emptied the dump volumes took place in another SMSplex, the devl sysplex's SMS (COMMDS) didn't have an accurate picture of free space. This is probably almost a worst case scenario for sharing between SMSplexes because huge files were created in one plex and deleted in another (as opposed to LOGR or every day allocations from a batch pool). But regardless it worked well until I turned on the striping. To answer your question, the high threshold was something like 85 and ISTR the low being something like 75. I set them to 95/10 and I think I also changed AUTO MIGRATE to I. When AUTO MIGRATE is I, migration is done when the space used exceeds the half way mark between the HIGH and LOW threshold. But another factor here was the migration of all the volumes in the pool to 3390-9. The more free space on a volume and in the pool, the better for this sharing since the other SMSplex may not have an accurate picture of the volume at allocation time. My problems were due to large dumps filling up a mod-3 and then they would get migrated from the prod plex, but the devl plex didn't know that space was available again (unless a new allocation fit and that volume was selected. So once the volumes were all changed from mod-3 to mod-9 along with the threshold changes, there was enough wiggle room for the allocations to take place without running the job. My statement above about worst case is because even though I have never set up shared batch volumes across the SMSplexes, I would guess it would work better with lots of smaller allocations on large volumes happening often from each plex. Every time a file is allocated or deleted from a particular plex, that plex would get a current picture of that space on the volume.We have shared LOGR across SMSplexes from day 1 and never had any problems at all and this is probably why. I just looked and all volumes in the LOGR pool are enabled on both SMSplexes also. There is a small development plex where there is also 2 SMSplexes ... but it is only a single volume in that pool shared between the 2 plexes. [...] I'm hoping we can fence allocations by system, and keep truly shared volumes (ENABLED everywhere) to one or zero. Operlog is the only problem child, and depending on where we use it and what RACF can do for us, would be the only reason for a globally ENABLED volume. It worked fine that way here before. I think they are all enabled now across the SMSplexes because there are 4 3390-9 in that pool now since our last DASD migration. It used to be 3 times as many volumes so they were easier to split up between the 2 SMSplexes. Regards, Mark -- Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS mailto:mzel...@flash.net Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html Systems Programming expert at http://expertanswercenter.techtarget.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: Non-SMS-managed LOGR offload data sets
Thanks for all the replies, I think I have a better idea of the problem here. It seems that Logger may inadvertently be the weak link when dasd is separated within a sysplex. I think the offloads happening on any connection was designed to increase availability if one system lost connections to DASD, but it also seems to be hinderance in these merged plexes. What it boils down to is that logger has to have access to the same set of data sets anywhere it connects to for everything to work properly. I'm going to take another look at the suggestions made a couple months ago, and see if there's anything logger can do. No promises, but maybe there's something we can add to restrict connections on systems connected to the wrong dasd. -Nick Jones Logger L3 -- 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: Non-SMS-managed LOGR offload data sets
Barbara Nitz nitz-...@gmx.net wrote in message news:listserv%201004140039341764.0...@bama.ua.edu... Answering all of last nights post in one: Big snip ... That 'foreign' subplex will be decommisioned soon. At this time we are again prone to paying more money if we keep TEST separate from PROD. Barbara, Are you sure you *have* to pay more if you don't merge Test and Prod? I ask this for more than one reason: First: each year IBM makes beautiful calculations for us how we could and might pay less if we change our license structure. Luckily I have a colleague that has studied the IBM pricing structure well and is able to calculate that our current pricing structure is yet cheaper than the proposed one. Second: because of the above, we can keep our Test and Prod sysplexes separated (allbeit on the same boxes) and it will cost no more than having those sysplexes merged. Does your company have somebody to validate the IBM proposed 'savings'? Kees. For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286 -- 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: Non-SMS-managed LOGR offload data sets
Are you sure you *have* to pay more if you don't merge Test and Prod? Having repeatedly asked my managers about just that (and my feelings about this idea are certainly known here - I have made enemies in the past because of it), I have to *believe* what they tell me. I am not privy to the contract details (nor am I likely to ever be), so even if I were to study the IBM licencing policy, I wouldn't have a clue what we *have* to pay. The technicians here are told that it is so and to merge the plexes. Defiance only goes so far And I am already stretching it. :-( Best 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
Re: Non-SMS-managed LOGR offload data sets
Barbara, Having performed IBM Software Asset Management in a past life, something doesn't quite add up here. But without the details, it is impossible to challenge your management's assertions. I would suggest that you take a different approach. Contact Al Sherkow (a...@sherkow.com) about this. I am sure he would be willing to give you or your management some limited free advice about current pricing options and his answers would be a sanity check of everyone's pricing assumptions. My $.02, Bob -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Barbara Nitz Sent: Wednesday, April 14, 2010 3:24 AM To: IBM-MAIN@bama.ua.edu Subject: Re: Non-SMS-managed LOGR offload data sets Are you sure you *have* to pay more if you don't merge Test and Prod? Having repeatedly asked my managers about just that (and my feelings about this idea are certainly known here - I have made enemies in the past because of it), I have to *believe* what they tell me. I am not privy to the contract details (nor am I likely to ever be), so even if I were to study the IBM licencing policy, I wouldn't have a clue what we *have* to pay. The technicians here are told that it is so and to merge the plexes. Defiance only goes so far And I am already stretching it. :-( Best 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 -- 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: Non-SMS-managed LOGR offload data sets
On Wed, 14 Apr 2010 00:39:34 -0500, Barbara Nitz nitz-...@gmx.net wrote: Answering all of last nights post in one: Mark, Anyway, I am commenting on it because the reason I had to use group name was due to 2 different DB2 subsystems on different systems in the same sysplex that had the same name. This particular system shares DASD, SMS, etc. but the applications aren't shared so there is no cross LPAR RRS considerations and I run this LPAR with GNAME= to the smfid. I beg to differ :-) (You're not surprised, are you?) Go to any system NOT connected to these log streams, preferably one that does not share DASD and SMS but *is* in the same sysplex. Use the RRS ISPF application and carefully look at all the input parms. (Do this at a time of little or no traffic, though.) Issue a browse command to one of the logstreams that *this* system is not connected to because it is NOT supposed to use this logstream. RRS will go out to logger with the definitions, LOGR in turn will say 'yes, I know that log stream' and have no problem whatsoever to *connect* to that log stream and read it out. Admittedly, the RRS application is smart enough to immediatly disconnect to the log stream after it got read. But if the log stream is big enough, it may take some time to read out the log stream. DURING THIS TIME YOU ARE EXPOSED TO THE RISK (sorry for the shouting). At the risk of repeating myself... I used the group name for the duplicate DB2 subsystem issue only. These systems are in the same sysplex, share DASD, catalogs and SMS (separate JES2). So I can't do what you asked. I guess that's a good thing. :-) snip In the meantime, I'm looking into RACF profiles to prevent connectors on non- owning images, which in turn restricts offloads. That will only work so long as I have a RACF database per subplex. RACF is one of the things shared in the environment I just mentioned. This will probably the solution that will be chosen here because it sounds like the least bit of work. Restrict connection to log streams by restricting the RRS ISPF application. It means that some sysprog TSO userids (we fortunately have different IDs in the subplexes, and RACF is separate, too) will need to get defined in the wrong RACF in order to explicitly forbid them to use this application (however I can do that). I think the problem with connecting to the log streams is that LOGR does it, and we have LOGR trusted. The RACF admin still has the scars from the time when LOGR was not trusted, so he does not want to remove that attribute. I guess because there has been single userid + multiple LPAR logon available prior to RRS and parallel sysplex use, coupled with the fact that there is still separation of JES2 and applications (for some of this environment / sysplex), when someone has a problem with RRS (or whatever), they logon to that LPAR to look at it. Not only that, if you get into the RRS dialogs, the default group name is there, so it takes some overt action to try and browse a logstream that is not for the system you are interested in. Boy, if we all knew then what we knew now. :-) At least the largest environment I support is all set up correctly. SYSPLEX = GRS = SMS = RACF = MAS etc. Mark -- Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS mailto:mzel...@flash.net Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html Systems Programming expert at http://expertanswercenter.techtarget.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: Non-SMS-managed LOGR offload data sets
On Wed, 14 Apr 2010 02:24:21 -0500, Barbara Nitz nitz-...@gmx.net wrote: Are you sure you *have* to pay more if you don't merge Test and Prod? Having repeatedly asked my managers about just that (and my feelings about this idea are certainly known here - I have made enemies in the past because of it), I have to *believe* what they tell me. I am not privy to the contract details (nor am I likely to ever be), so even if I were to study the IBM licencing policy, I wouldn't have a clue what we *have* to pay. The technicians here are told that it is so and to merge the plexes. Defiance only goes so far And I am already stretching it. :-( PSLC is pretty simple. Your qualifying sysplex (biggest one) has to be 50% or more of the used capacity on each box. So even if you have a very large sysplex but also have lots of small sysplexes or monoplexes due to consolidations etc., PSLC qualification can be difficult. In the environment I work in, we barely make it work and it's a constant battle to keep it that way. Luckily, the largest sysplex is really a true sysplex with applications sysplex enabled, so we can do things like move CICS regions from one LPAR to another to change the mix. However, occasionally, we've had to move an entire LPAR from one box to another or some other workload (for example, SAS). Another problem is if you have a box that doesn't have any LPARs that are part of the qualifying sysplex. None of the IBM software on that LPAR would qualify for PSLC. Mark -- Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS mailto:mzel...@flash.net Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html Systems Programming expert at http://expertanswercenter.techtarget.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: Non-SMS-managed LOGR offload data sets
Mark Zelden mzel...@flash.net wrote in message news:listserv%201004140856187730.0...@bama.ua.edu... On Wed, 14 Apr 2010 02:24:21 -0500, Barbara Nitz nitz-...@gmx.net wrote: Are you sure you *have* to pay more if you don't merge Test and Prod? Having repeatedly asked my managers about just that (and my feelings about this idea are certainly known here - I have made enemies in the past because of it), I have to *believe* what they tell me. I am not privy to the contract details (nor am I likely to ever be), so even if I were to study the IBM licencing policy, I wouldn't have a clue what we *have* to pay. The technicians here are told that it is so and to merge the plexes. Defiance only goes so far And I am already stretching it. :-( PSLC is pretty simple. Your qualifying sysplex (biggest one) has to be 50% or more of the used capacity on each box. 80% is the value I heard. Kees. For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286 -- 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: Non-SMS-managed LOGR offload data sets
I went through all this in a previous employer. Due to acquisitions, we merged 4 plexes into one site, into one shamplex. Only one small system was able to be combined with another, wound up with 3 MAS'es, 3 RACFDB's, 3 SMSplexes, etc. Chose to send LOGREC data to LOGR for the contractual obligation. Only a small amount of DASD was shared, we used the IEFDB401 exit to send all logger offloads to one common esoteric and one shared catalog. It was sort of a pain, but it worked for the most part. There were challenges at DR testing, keeping the proper logstream definitions done from the proper systems. Dana -- 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: Non-SMS-managed LOGR offload data sets
W dniu 2010-04-14 15:59, Vernooij, CP - SPLXM pisze: [...] PSLC is pretty simple. Your qualifying sysplex (biggest one) has to be 50% or more of the used capacity on each box. 80% is the value I heard. HEARD? Is it documented anyhwhere? I have SEEN IBM documents describing Terms and Conditions for qualified PS. *No percentage* is mentioned. Maybe someone made a mistake and lost some paragraph in translation, but there was percentage. That would be fine - you always could set up dummyplex just to satisfy the TsCs. Looks to optimistic. BTW: What about the following scenario: CPC1, big LPAR SYSA1 sysplexed with small LPAR SYSA2 on CPC2. And big LPAR SYSB1 on CPC2 is syplexed with small one SYSB2 on CPC1. In fact everything is sysplexed, but no sysplex fill the percentage treshold. -- Radoslaw Skorupka Lodz, Poland -- BRE Bank SA ul. Senatorska 18 00-950 Warszawa www.brebank.pl Sd Rejonowy dla m. st. Warszawy XII Wydzia Gospodarczy Krajowego Rejestru Sdowego, nr rejestru przedsibiorców KRS 025237 NIP: 526-021-50-88 Wedug stanu na dzie 01.01.2009 r. kapita zakadowy BRE Banku SA (w caoci wpacony) wynosi 118.763.528 zotych. W zwizku z realizacj warunkowego podwyszenia kapitau zakadowego, na podstawie uchway XXI WZ z dnia 16 marca 2008r., oraz uchway XVI NWZ z dnia 27 padziernika 2008r., moe ulec podwyszeniu do kwoty 123.763.528 z. Akcje w podwyszonym kapitale zakadowym BRE Banku SA bd w caoci opacone. -- 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: Non-SMS-managed LOGR offload data sets
On Wed, 14 Apr 2010 19:06:07 +0200, R.S. r.skoru...@bremultibank.com.pl wrote: W dniu 2010-04-14 15:59, Vernooij, CP - SPLXM pisze: [...] PSLC is pretty simple. Your qualifying sysplex (biggest one) has to be 50% or more of the used capacity on each box. 80% is the value I heard. HEARD? Is it documented anyhwhere? I have SEEN IBM documents describing Terms and Conditions for qualified PS. *No percentage* is mentioned. Huh?! http://www-03.ibm.com/systems/z/resources/swprice/sysplex/index.html -- Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS mailto:mzel...@flash.net Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html Systems Programming expert at http://expertanswercenter.techtarget.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: Non-SMS-managed LOGR offload data sets
PSLC is pretty simple. Your qualifying sysplex (biggest one) has to be 50% or more of the used capacity on each box. 80% is the value I heard. HEARD? Is it documented anyhwhere? It was in 1998. We got PSLC by running SYSLOGR and Batch on the CEC. I don't know if it's more complex now. The next two companies I worked for got better pricing through WLC. - 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
Re: Non-SMS-managed LOGR offload data sets
In keeping with the consolidated response (if I'm not losing too much context): Mark, Yes, I recall the striping issue you had. I think we can avoid that. Yes, the allocate/delete job is what I referred to. Glad to hear that's not needed any longer. One less hurdle for our Storage team. Band-Aids can be tough to remove. In which direction did you adjust the migration threshold? I just looked and all volumes in the LOGR pool are enabled on both SMSplexes also. There is a small development plex where there is also 2 SMSplexes ... but it is only a single volume in that pool shared between the 2 plexes. [...] I'm hoping we can fence allocations by system, and keep truly shared volumes (ENABLED everywhere) to one or zero. Operlog is the only problem child, and depending on where we use it and what RACF can do for us, would be the only reason for a globally ENABLED volume. Don't shoot the messenger [...] Only trying to learn from others' experience. I've already made a secondary career out of mopping up my bloody footprints. Boy, if we all knew then what we knew now. :-) I'd have run like hell... joined a circus - anything but this. At least the largest environment I support is all set up correctly. SYSPLEX = GRS = SMS = RACF = MAS etc. With any luck, we'll get there some day. Nick, I think the marketing solution would either be more restrictive or more costly. Not sure how it would be more restrictive than I would want it. Would the overhead for offload system selection really be that bad? There might be opportunity for conflicts if I set my options inappropriately, but I would hope such a feature would have accompanying smarts built into IXCMIAPU. RACF might help. [...] That's the hope. I'm requesting CLAUTH for LOGSTRM on our sandbox, and we'll go from there. Turning off logger would do it too, but probably not ideal. That would be an understatement. We have DB2 on almost every image. I don't think it works too well without RRS, which in turn doesn't work too well without Logger. This may have been discussed before, but have either of you considered using SMS classes to fence test and production dasd from each other, and use the LS_xxxClas / STG_xxxCLAS log stream parameters to separate test and production log streams? [...] Mark's method of ENABLE/DISNEW in a prior post is another means to this end. With all volumes ENABLEd across SMSPlex boundaries, this LS/STG STORCLAS/MGMTCLASS would probably work as well, provided we share DASD, which we currently do not. Furthermore... [...info on GROUP(TEST) vs GROUP(PRODUCTION) as of z/OS 1.8...] However, this doesn't help clients who want to separate workloads on a system basis. Exactly. Plus, this would not work for Operlog, nor SMF (big disappointment), nor LOGREC. This sort of protection is minimal, and really does not help our particular situation. I have no problem making a logstream or structure bigger, allowing for extents, asking for more DASD, as the need arises. Is there a reason for such a stringent separation of DASD? Many. Is it for failure prevention? Somewhat, yes. We have two sites with production in each, and DR (via PPRC synchronous) in the opposite. Even if our new vendor supported basic hyperswap (unknown, but unlikely AFAIK), or GDPS hyperswap (even less likely), setting up and maintaining a failover configuration with shared DASD across sites would be a nightmare. Right now, believe it or not, even though we have a relatively manual process (scripted with PPRC MM), because the DASD is fenced off, we've got it down to about 30 minutes. If we wanted to share and mirror DASD, we would have to pick a site as the primary and move half our production and development data. Sysplex DASD (CDS', PARMLIB, USS ROOT) are the exception, but these are NOT mirrored. For planned events, we manually swap these datasets using a SystemRexx script for the CDS', SETLOAD for PARMLIB, and F OMVS,NEWROOT for USS. For unplanned events, we still need a sysplex-wide IPL with an alternate LOADxx. When we upgrade from 1.10 to 1.12,
Re: Non-SMS-managed LOGR offload data sets
On Mon, 12 Apr 2010 23:56:56 -0500, Barbara Nitz nitz-...@gmx.net wrote: Yes. Mark, look at group name in RRS to separate logging groups - I think this was intended to separate test and prod, and then look at the RRS panels where you can freely choose the group name; the rest is simple logstream definition and workings. And this is just the 'easy' way using only IBM-supplied means to possibly corrupt a log stream. If someone thinks up another way programmatically, I just shudder! Was this meant for Nick? Anyway, I am commenting on it because the reason I had to use group name was due to 2 different DB2 subsystems on different systems in the same sysplex that had the same name. This particular system shares DASD, SMS, etc. but the applications aren't shared so there is no cross LPAR RRS considerations and I run this LPAR with GNAME= to the smfid. Mark -- Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS mailto:mzel...@flash.net Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html Systems Programming expert at http://expertanswercenter.techtarget.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: Non-SMS-managed LOGR offload data sets
On Mon, 12 Apr 2010 08:08:22 -0500, Mark Zelden mzel...@flash.net wrote: BTW, I'm not sure if I mentioned this last year, but they way we shared these pools between SMSplexes usually was by having the SMS status in the owning SMSplex as ENABLE and then the volumes owned by the other SMSplex in the shared group set to DISNEW and visa versa. A-HA! If you did, I missed it. Do you still update the non-owning COMMDS periodically, as you described then? DISNEW would allay my nerves, but our Storage team would have to really be on top things. To Nick Jones: everything Barbara said, and then some. These threads have come up more than once in the last year or two, with many contributors. As long IBM marketing dangles the carrot, coroporate IT will continue to support that, and only that, which is necessary to save $$. Shamplex has become part of the nomenclature... As for where support to restrict offload locations, this too was proposed by a poster last year, and so well-written that some of us ran to the books to read what we thought we missed! I would definitely make use of the feature. In the meantime, I'm looking into RACF profiles to prevent connectors on non- owning images, which in turn restricts offloads. That will only work so long as I have a RACF database per subplex. I reckon we'd better have SMS sorted out before we start RACF data sharing... Regards, Art Gutowski Ford Motor Company -- 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: Non-SMS-managed LOGR offload data sets
On Tue, 13 Apr 2010 10:14:24 -0500, Arthur Gutowski aguto...@ford.com wrote: On Mon, 12 Apr 2010 08:08:22 -0500, Mark Zelden mzel...@flash.net wrote: BTW, I'm not sure if I mentioned this last year, but they way we shared these pools between SMSplexes usually was by having the SMS status in the owning SMSplex as ENABLE and then the volumes owned by the other SMSplex in the shared group set to DISNEW and visa versa. A-HA! If you did, I missed it. Do you still update the non-owning COMMDS periodically, as you described then? DISNEW would allay my nerves, but our Storage team would have to really be on top things. For the dump pool, I had the storage admin enable all the volumes everywhere to give it a bigger pool. If you recall, we never had problems with that pool until I turned on striping per the SVC dump performance paper / recommendations. SMS allocation thresholds work differently when striping is involved.But to answer your question, and assuming by updating the COMMDS you are asking if I run a job that allocates / deletes a 1 trk data set on each volume, the answer is no. After I adjusted the migration thresholds we never had a problem again. I can't remember if that pool was on 3390-3s or mod 9s when we discussed this last. It is on mod-9 now so space is less of an issue because of that too. I just looked and all volumes in the LOGR pool are enabled on both SMSplexes also. There is a small development plex where there is also 2 SMSplexes ... but it is only a single volume in that pool shared between the 2 plexes. This whole mess is because our 2 SAP LPARs - prod/devl need to share SMS to clone DB2s, but each LPAR belongs to the devl / prod sysplex. Don't shoot the messenger, I wasn't around when these choices were made years ago when creating a priceplex. At that time no one understood that these unnatural acts could cause problems down the line. No one knew or understood that MIM wouldn't help with HFS and PDSE sharing either. Mark -- Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS mailto:mzel...@flash.net Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html Systems Programming expert at http://expertanswercenter.techtarget.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: Non-SMS-managed LOGR offload data sets
On Apr 13, 12:57 am, nitz-...@gmx.net (Barbara Nitz) wrote: Nick, from your email I figured you're somewhere in LOGR development :-) And I am absolutely glad someone finally 'gets' my paranoia. I have a hard time getting the problem across to my colleagues, too! Mostly because they don't really understand how offload works. Barbara, Yes i'm in logger development. Also, keep in mind that I am not saying that we already *had* a corrupted RRS log stream, I just see a big timing window (that we will probably hit at the first opportunity - we always hit obscure timing problems) if we activate LOGR in both halves. Usually the system that does the offload for a log stream is the system that does the write causing the HIGHOFFLOAD threshold to be exceeded. So if your utility program ran on your TEST side, but didn't write to the log stream, the risk would be smaller. But it doesn't always have to be that way. Offloads can be started for various reasons such as structure events, recovery, and offload failures on other systems. So the worry is warranted. Now he tells me! Would you please explain to the IBM pricing people that their PLSC pricing schemes make customers do this which is absolutely contrary to the parallel sysplex design points?!? I'm not sure I have that much sway, but I definitely sympathize with the ironic nature of the setup. Art, As long IBM marketing dangles the carrot, coroporate IT will continue to support that, and only that, which is necessary to save $$. Shamplex has become part of the nomenclature... As for where support to restrict offload locations, this too was proposed by a poster last year, and so well-written that some of us ran to the books to read what we thought we missed! I would definitely make use of the feature. In the meantime, I'm looking into RACF profiles to prevent connectors on non- owning images, which in turn restricts offloads. That will only work so long as I have a RACF database per subplex. I reckon we'd better have SMS sorted out before we start RACF data sharing... I think the marketing solution would either be more restrictive or more costly. But perhaps there are a few things that can be done with existing functions that might help. RACF might help. If you can prevent logstreams from being used on systems with RACF or prevent data sets from being allocated that have log stream data set names, that might avoid the contention. Turning off logger would do it too, but probably not ideal. This may have been discussed before, but have either of you considered using SMS classes to fence test and production dasd from each other, and use the LS_xxxClas / STG_xxxCLAS log stream parameters to separate test and production log streams? If a production log stream accidentally connected on a test system, it might be able to get to the right dasd pool, and something truly shared like operlog might work for the whole plex. In V1R8 logger did add an option to separate test and production work on a log stream basis, but it was intend for clients who wanted to run test and production work on the same system. Logger sets up separate tasks for test and production work, and specifying the GROUP(TEST) or GROUP(PRODUCTION) option on the log stream definition will tell the log stream wich set of tasks to use. There are also restrictions enforced, such as a test log stream can't connect to a structure with a production log stream connected to it. It also prevents test log streams from using more than 25% of the structures. The goal was to prevent TEST log streams from harming PRODUCTION log streams. However, this doesn't help clients who want to separate workloads on a system basis. Is there a reason for such a stringent separation of DASD? Is it for failure prevention? Does accounting data get messed up? It sounds to me like a completely separate sysplex is out of the question, because it costs more than extra set of systems in an existing plex. Maybe it would help if I understood what's being walled out and what's being walled in. -Nick Jones Logger L3 -- 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: Non-SMS-managed LOGR offload data sets
Hi Barbara, we have a similar setupbut because we merged two production Parallel Sysplexes. history: 2 separate datacenters in same city. 2nd prod system had been CLONED from first and modified slightlythen had 10 years growth. We also had each datacenter being the DR site of the other. Sovereign RISK! - had to move DR site off country. Now no reason for 2 data centers in same city.so relocate machines from 2nd site to 1st. Then save money and merge the 2 separate Parallel Sysplexes into one. End up with 3 x JES2 MASplex / SMSPlex / HSMPlex in single Parallel Sysplex. (that 2nd site has been subplexed always...but only one subset had DB2.) Ok...had to have LOGR.reasons included heavy DB2 Data Sharing in both original sites. So we set up a pool of DASD that was accessible from every production system. Each SMSPlex was given a subset of that DASD to manage. So each disk volume has only one SMS owner. Set up common User Catalog, connected to each system MastCat. It doesn't matter which LOGR does the OFFLOAD.because the SMS managed offload dataset is placed onto the shared disk, and cataloged in common UserCat. Been operating like this for 12 months. Probably stay this way for a long time. The migration path from this BronzePlex to the ultimate PlatinumPlex looks almost impossible to complete. 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
Re: Non-SMS-managed LOGR offload data sets
Answering all of last nights post in one: Mark, Anyway, I am commenting on it because the reason I had to use group name was due to 2 different DB2 subsystems on different systems in the same sysplex that had the same name. This particular system shares DASD, SMS, etc. but the applications aren't shared so there is no cross LPAR RRS considerations and I run this LPAR with GNAME= to the smfid. I beg to differ :-) (You're not surprised, are you?) Go to any system NOT connected to these log streams, preferably one that does not share DASD and SMS but *is* in the same sysplex. Use the RRS ISPF application and carefully look at all the input parms. (Do this at a time of little or no traffic, though.) Issue a browse command to one of the logstreams that *this* system is not connected to because it is NOT supposed to use this logstream. RRS will go out to logger with the definitions, LOGR in turn will say 'yes, I know that log stream' and have no problem whatsoever to *connect* to that log stream and read it out. Admittedly, the RRS application is smart enough to immediatly disconnect to the log stream after it got read. But if the log stream is big enough, it may take some time to read out the log stream. DURING THIS TIME YOU ARE EXPOSED TO THE RISK (sorry for the shouting). Obviously I could not do too much testing because any system with enough traffic to even have entries in the RRS log streams were production systems, and I did not want to risk a cold start. But it took several minutes (!) to browse the archive log stream (I did not dare use one of the non-optional ones) from the 'wrong' side. Art and Mark, I am severly hampered by solid non-knowledge of SMS details. I have heard all of that vocabulary, but I was never in a position to actually have to administer any of this, so all I can do is tuck away all of these details and show them to my admin when the time comes (I know that the admin does not want to change anything in the SMS setup, so he is not volunteering anything in terms of making it happen. I need all the information I can get to tell management what can be done, even if I don't understand the implications...) Bruce and Nick, our story is even worse. Parallel sysplex was introduced here in the late nineties, way before I joined the company. At the time *IBM* recommended three parallel sysplexes, sysprog sandplex for maintenance, applications development sysplex called TEST and production sysplex called PROD. For some reason (mostly hysterical), TEST and PROD were never separate plexes, so they shared DASD, SMS, RACF, TAPES, Automation etc. There were several incidents where changes to TEST caused problems in PROD. When I joined the company in 2001, there was a project underway for more than a year already to separate TEST and PROD because the autors had demanded a more secure PROD environment. This finally happened in 2002. Some time later we insourced a parallel sysplex from another company. Management decided to merge that 'foreign' sysplex with our TEST sysplex to save money. The 'foreign' sysplex did have completely different naming conventions and it did not use LOGR, so the merge was relatively easy. Took only about three months from conception to fulfilment. That 'foreign' subplex will be decommisioned soon. At this time we are again prone to paying more money if we keep TEST separate from PROD. I am in charge of the project to merge, and I have severe stomachaches for the LOGR part, especially as this time around naming conventions are identical *and* I have to find a way to make LOGR/RRS work on both subplexes because they already run there. Bruce, your setup sounds like the one I would *like* to have, because it will enable future LOGR applications (as I said, I would like to use SMF log streams). The migration path from this BronzePlex to the ultimate PlatinumPlex looks almost impossible to complete. Would not even be attempted here. Art, In the meantime, I'm looking into RACF profiles to prevent connectors on non- owning images, which in turn restricts offloads. That will only work so long as I have a RACF database per subplex. This will probably the solution that will be chosen here because it sounds like the least bit of work. Restrict connection to log streams by restricting the RRS ISPF application. It means that some sysprog TSO userids (we fortunately have different IDs in the subplexes, and RACF is separate, too) will need to get defined in the wrong RACF in order to explicitly forbid them to use this application (however I can do that). I think the problem with connecting to the log streams is that LOGR does it, and we have LOGR trusted. The RACF admin still has the scars from the time when LOGR was not trusted, so he does not want to remove that attribute. The problem I have with this is that this would only fill in the hole *that I know of*. What if someone comes up with some other way to make
Re: Non-SMS-managed LOGR offload data sets
Nick, My only advice, if such a thing works, is that you should consider separate HLQ or EHLQ values for each log stream that has the same name in both sysplexes. That would avoid thrashing when allocating offload data sets, where the sysplexes would be competing for the same data set names. I took a look at some old Logger APARs, and found OA12937, which corrected a ENQ bug with the same log stream name used in multiple sysplexes in the same GRS complex (one full sysplex, and numerous monoplexes). Maybe you misunderstood what I was saying: I am talking genuine parallel sysplex, that for no technical but purely pricing reasons (IBM pricing) has been artificially separated into two subplexes. These two subplexes share of course ISGLOCK and everything that is truly, non-reconfigurably sysplex scope. LOGR is a problem is such a setup, and no amount of naming conventions for offload datasets will help, when the logstream definition is truly sysplex scope (as in operlog). As there is only one logr policy, so there is no way to define two different HLQs for such a log stream. And RRS presents a different problem, as it is frighteningly easy to corrupt RRS logstreams necessitating RRS cold starts. And that is true even when certain parts of the sysplex use different RRS group names. The RRS ISPF application does not care where the logstream is supposed to 'reside', it connects to the 'wrong side' when instructed to do so by a human who doesn't know the implications). That presents a timing exposure, as the wrong half of the sysplex now has a connection to that logstream. If offload happens right then, it may happen on the wrong side. Offload will succeed (with a dataset in master catalog), but the log stream will be corrupted. Hence the requirement to have a pool of volumes for LOGR offload data sets that is accessible to both halves of the sysplex, when each half has it's own SMS configuration and is not supported by IBM to share a pool in two SMSs (even if it works). Hence my 'survey'. The only alternative supported is non- SMS, and to make it go to certain volumes (and not generally storage mounted volsers) is the IEFDB401 exit as described in 'setting up a sysplex' - that apparently nobody uses. Last year we've discussed this, and a suggestion was made to define in the LOGR policy via keyword *where* offload might occur. That would take care of our problem (and I don't think we are the only customer to have such an artificially separated sysplex - I'm apparently the only one paranoid enough not to risk a data integrity problem that RRS answers by cold-starting taking down the new-fangled applications such as Websphere.) Best 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: Non-SMS-managed LOGR offload data sets
Barbara Nitz nitz-...@gmx.net wrote in message news:listserv%201004120111313731.0...@bama.ua.edu... Nick, My only advice, if such a thing works, is that you should consider separate HLQ or EHLQ values for each log stream that has the same name in both sysplexes. That would avoid thrashing when allocating offload data sets, where the sysplexes would be competing for the same data set names. I took a look at some old Logger APARs, and found OA12937, which corrected a ENQ bug with the same log stream name used in multiple sysplexes in the same GRS complex (one full sysplex, and numerous monoplexes). Maybe you misunderstood what I was saying: I am talking genuine parallel sysplex, that for no technical but purely pricing reasons (IBM pricing) has been artificially separated into two subplexes. These two subplexes share of course ISGLOCK and everything that is truly, non-reconfigurably sysplex scope. LOGR is a problem is such a setup, and no amount of naming conventions for offload datasets will help, when the logstream definition is truly sysplex scope (as in operlog). As there is only one logr policy, so there is no way to define two different HLQs for such a log stream. And RRS presents a different problem, as it is frighteningly easy to corrupt RRS logstreams necessitating RRS cold starts. And that is true even when certain parts of the sysplex use different RRS group names. The RRS ISPF application does not care where the logstream is supposed to 'reside', it connects to the 'wrong side' when instructed to do so by a human who doesn't know the implications). That presents a timing exposure, as the wrong half of the sysplex now has a connection to that logstream. If offload happens right then, it may happen on the wrong side. Offload will succeed (with a dataset in master catalog), but the log stream will be corrupted. Hence the requirement to have a pool of volumes for LOGR offload data sets that is accessible to both halves of the sysplex, when each half has it's own SMS configuration and is not supported by IBM to share a pool in two SMSs (even if it works). Hence my 'survey'. The only alternative supported is non- SMS, and to make it go to certain volumes (and not generally storage mounted volsers) is the IEFDB401 exit as described in 'setting up a sysplex' - that apparently nobody uses. Last year we've discussed this, and a suggestion was made to define in the LOGR policy via keyword *where* offload might occur. That would take care of our problem (and I don't think we are the only customer to have such an artificially separated sysplex - I'm apparently the only one paranoid enough not to risk a data integrity problem that RRS answers by cold-starting taking down the new-fangled applications such as Websphere.) Best regards, Barbara Nitz Alltogehter, in my opnion you should, and are fully entitled to, *demand* a storage configuration that conforms to IBM's Parallel Sysplex requirements in order to guarantee the availability and operation of your systems. Whatever the bookkeepers invent to cut down costs should never be allowed to compromise the operation of the system and raise the possibility that IBM refuses to accept problems because of a off-standard (or anti-standard) configuration. Kees. For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286 -- 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: Non-SMS-managed LOGR offload data sets
On Mon, 12 Apr 2010 01:11:31 -0500, Barbara Nitz nitz-...@gmx.net wrote: The only alternative supported is non- SMS, and to make it go to certain volumes (and not generally storage mounted volsers) is the IEFDB401 exit as described in 'setting up a sysplex' - that apparently nobody uses. STORAGE mounted volumes isn't the end of the world. And if neither half is using it today, it sounds a viable option. As I mentioned in my last post about this, we have a very large sysplex that still has a lot of their logger data sets non-sms managed going to storage volumes. Last year we've discussed this, and a suggestion was made to define in the LOGR policy via keyword *where* offload might occur. That would take care of our problem (and I don't think we are the only customer to have such an artificially separated sysplex - I'm apparently the only one paranoid enough not to risk a data integrity problem that RRS answers by cold-starting taking down the new-fangled applications such as Websphere.) I don't recall that. I guess I should search the archives, but I did look at setting up a sysplex and don't know what keyword you might be referring to. BTW, I'm not sure if I mentioned this last year, but they way we shared these pools between SMSplexes usually was by having the SMS status in the owning SMSplex as ENABLE and then the volumes owned by the other SMSplex in the shared group set to DISNEW and visa versa. Mark -- Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS mailto:mzel...@flash.net Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html Systems Programming expert at http://expertanswercenter.techtarget.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: Non-SMS-managed LOGR offload data sets
Maybe you misunderstood what I was saying: I am talking genuine parallel sysplex, that for no technical but purely pricing reasons (IBM pricing) has been artificially separated into two subplexes. These two subplexes share of course ISGLOCK and everything that is truly, non-reconfigurably sysplex scope. LOGR is a problem is such a setup, and no amount of naming conventions for offload datasets will help, when the logstream definition is truly sysplex scope (as in operlog). As there is only one logr policy, so there is no way to define two different HLQs for such a log stream. And RRS presents a different problem, as it is frighteningly easy to corrupt RRS logstreams necessitating RRS cold starts. And that is true even when certain parts of the sysplex use different RRS group names. The RRS ISPF application does not care where the logstream is supposed to 'reside', it connects to the 'wrong side' when instructed to do so by a human who doesn't know the implications). That presents a timing exposure, as the wrong half of the sysplex now has a connection to that logstream. If offload happens right then, it may happen on the wrong side. Offload will succeed (with a dataset in master catalog), but the log stream will be corrupted. Hence the requirement to have a pool of volumes for LOGR offload data sets that is accessible to both halves of the sysplex, when each half has it's own SMS configuration and is not supported by IBM to share a pool in two SMSs (even if it works). Hence my 'survey'. The only alternative supported is non- SMS, and to make it go to certain volumes (and not generally storage mounted volsers) is the IEFDB401 exit as described in 'setting up a sysplex' - that apparently nobody uses. Last year we've discussed this, and a suggestion was made to define in the LOGR policy via keyword *where* offload might occur. That would take care of our problem (and I don't think we are the only customer to have such an artificially separated sysplex - I'm apparently the only one paranoid enough not to risk a data integrity problem that RRS answers by cold-starting taking down the new-fangled applications such as Websphere.) Best regards, Barbara Nitz Hi Barbara, Ahh now I understand your problem. So If you try to cut your sysplex in half but still call it a sysplex, problems happen when subplex A tries to use a log stream designated subplex B. The RRS panels don't know what system they're being sent to, but once there is a Logger connection, Logger can offload there. If it gets a connection on the wrong subplex, an offload can occur using the wrong dasd, once RRS tries to use data on the wrong dasd in the alternate subplex, the corruption occurs. I had brought up the log stream option to pick which systems offload to my team before, but we didn't fully understand the context. I'm not sure we can help much, because not sharing resources is contrary to the design of the sysplex, but I'll keep this in mind. It would be interesting to know if other clients are having similar problems. Nick Jones Logger L3 -- 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: Non-SMS-managed LOGR offload data sets
Nick, from your email I figured you're somewhere in LOGR development :-) And I am absolutely glad someone finally 'gets' my paranoia. I have a hard time getting the problem across to my colleagues, too! Mostly because they don't really understand how offload works. Ahh now I understand your problem. So If you try to cut your sysplex in half but still call it a sysplex, problems happen when subplex A tries to use a log stream designated subplex B. The RRS panels don't know what system they're being sent to, but once there is a Logger connection, Logger can offload there. If it gets a connection on the wrong subplex, an offload can occur using the wrong dasd, once RRS tries to use data on the wrong dasd in the alternate subplex, the corruption occurs. Yes. Mark, look at group name in RRS to separate logging groups - I think this was intended to separate test and prod, and then look at the RRS panels where you can freely choose the group name; the rest is simple logstream definition and workings. And this is just the 'easy' way using only IBM-supplied means to possibly corrupt a log stream. If someone thinks up another way programmatically, I just shudder! Oh, and we currently have such a split subplex-in-one-sysplex setup. I have refused to activate LOGR in one half and have the DB2 people as enemies now, because apparently some of their dynamic setups *need* RRS to show up in any display. They did not get that this has nothing to do with RRS, but rather with the underlying LOGR services. And even though I made sure that operlog is NOT used in the wrong half, we regularly have corrupted operlog log streams because they got offloaded in the wrong half. Fortunately operlog just shrugs and goes on. I also think that with this (pricing) setup I will do everything I can NOT to use SMF logging, which I would have loved to turn on! Pity. I had brought up the log stream option to pick which systems offload to my team before, but we didn't fully understand the context. I'm not sure we can help much, because not sharing resources is contrary to the design of the sysplex, but I'll keep this in mind. It would be interesting to know if other clients are having similar problems. Now he tells me! Would you please explain to the IBM pricing people that their PLSC pricing schemes make customers do this which is absolutely contrary to the parallel sysplex design points?!? Also, keep in mind that I am not saying that we already *had* a corrupted RRS log stream, I just see a big timing window (that we will probably hit at the first opportunity - we always hit obscure timing problems) if we activate LOGR in both halves. Nick, I am also offering to have a conference call with you if you feel that will help to better understand my concerns. Best 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
Re: Non-SMS-managed LOGR offload data sets
On Wed, 7 Apr 2 What I need to have accessible from all systems in the sysplex (share) is a number of volumes that can contain LOGR offload data sets from two subplexes that otherwise know nothing about it each other (in theory). I am also told that it is 'too much work' to make it one SMS config for the full sysplex. And I cannot validate that statement - not my area. Regards, Barbara My only advice, if such a thing works, is that you should consider separate HLQ or EHLQ values for each log stream that has the same name in both sysplexes. That would avoid thrashing when allocating offload data sets, where the sysplexes would be competing for the same data set names. I took a look at some old Logger APARs, and found OA12937, which corrected a ENQ bug with the same log stream name used in multiple sysplexes in the same GRS complex (one full sysplex, and numerous monoplexes). That was in 2005 and before that logger wasn't aware that such an environment existed. In the apar logger added DOC that says: z/OS MVS Setting Up a Sysplex |--- LOCATION IN PUBLICATION ---| Chapter 9 Planning for System Logger Applications Section 9.4 Preparing to Use System Logger Applications Section 9.4.1 Understand the Requirements for Syste Logger Section 9.4.1.2 Sysplex Requirement GRS Complex considerations: If the environment System Logger is executing in consists of more than one sysplex in a GRS complex, with like-named logstreams defined on more multiple sysplexes, the following requirements must be met: - The GRS Ring complex contains at most one multisystem sysplex. - One of the following must be true: A. Each like-named logstream in the GRS complex must have a unique EHLQ/HLQ. B. The installation must ensure the seperation of System Logger logstream resources (seperate catalogs and DASD). Further, the logstream offload dataset naming convention must be included in the inclusion list as discussed in z/OS MVS Planning: Global Resource Serialization, Chapter 1.2.7.10 -- 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: Non-SMS-managed LOGR offload data sets
On Wed, 7 Apr 2010 04:27:41 -0500, Barbara Nitz nitz-...@gmx.net wrote: What I need to have accessible from all systems in the sysplex (share) is a number of volumes that can contain LOGR offload data sets from two subplexes that otherwise know nothing about it each other (in theory). I am also told that it is 'too much work' to make it one SMS config for the full sysplex. And I cannot validate that statement - not my area. Regards, Barbara My only advice, if such a thing works, is that you should consider separate HLQ or EHLQ values for each log stream that has the same name in both sysplexes. That would avoid thrashing when allocating offload data sets, where the sysplexes would be competing for the same data set names. I took a look at some old Logger APARs, and found OA12937, which corrected a ENQ bug with the same log stream name used in multiple sysplexes in the same GRS complex (one full sysplex, and numerous monoplexes). That was in 2005 and before that logger wasn't aware that such an environment existed. In the apar logger added DOC that says: z/OS MVS Setting Up a Sysplex |--- LOCATION IN PUBLICATION ---| Chapter 9 Planning for System Logger Applications Section 9.4 Preparing to Use System Logger Applications Section 9.4.1 Understand the Requirements for Syste Logger Section 9.4.1.2 Sysplex Requirement GRS Complex considerations: If the environment System Logger is executing in consists of more than one sysplex in a GRS complex, with like-named logstreams defined on more multiple sysplexes, the following requirements must be met: - The GRS Ring complex contains at most one multisystem sysplex. - One of the following must be true: A. Each like-named logstream in the GRS complex must have a unique EHLQ/HLQ. B. The installation must ensure the seperation of System Logger logstream resources (seperate catalogs and DASD). Further, the logstream offload dataset naming convention must be included in the inclusion list as discussed in z/OS MVS Planning: Global Resource Serialization, Chapter 1.2.7.10 -- 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: Non-SMS-managed LOGR offload data sets
On Wed, 7 Apr 2010 03:48:32 -0500, Barbara Nitz nitz-...@gmx.net wrote: Unscientific survey: How many of you use truly non-SMS-managed LOGR datasets? As in: Using the two model data sets and an IEFDB401 exit that specifies the DALLIKE text unit? All SMS-managed, AFAIK. No IEFDB401 exit. How many of you 'share' a pool of DASD (for LOGR data sets) in two SMSs? Nope, separate SMSPlexen for separate managed DASD. (Don't ask me why I am asking.) Too late, apparently (the trouble with daily digest), but the thread went right where I did. We hear 'too much' as well, but I don't argue - we are all in the same boat (where's my paddle?). I entertained Mark's solution, but I am nervous with production logstreams. Dump pools aren't critical, but we have enough trouble with logstream pools as it is (our sandbox went casters-up yesterday, and because I was playing with CF MAINTMODE, I thought it was me, at first). I don't want to further frustrate our storage managers with an unsupported, albeit workable, tactical fix. We'll just deal with it until we can merge SMS'. Regards, Art Gutowski Ford Motor Company -- 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
Non-SMS-managed LOGR offload data sets
Unscientific survey: How many of you use truly non-SMS-managed LOGR datasets? As in: Using the two model data sets and an IEFDB401 exit that specifies the DALLIKE text unit? How many of you 'share' a pool of DASD (for LOGR data sets) in two SMSs? (Don't ask me why I am asking.) 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
Re: Non-SMS-managed LOGR offload data sets
Barbara Nitz pisze: Unscientific survey: How many of you use truly non-SMS-managed LOGR datasets? As in: Using the two model data sets and an IEFDB401 exit that specifies the DALLIKE text unit? My LOGR datasets are always SMS-managed. In fact I don't see any reason to get rid of SMS. -- Radoslaw Skorupka Lodz, Poland -- BRE Bank SA ul. Senatorska 18 00-950 Warszawa www.brebank.pl Sd Rejonowy dla m. st. Warszawy XII Wydzia Gospodarczy Krajowego Rejestru Sdowego, nr rejestru przedsibiorców KRS 025237 NIP: 526-021-50-88 Wedug stanu na dzie 01.01.2009 r. kapita zakadowy BRE Banku SA (w caoci wpacony) wynosi 118.763.528 zotych. W zwizku z realizacj warunkowego podwyszenia kapitau zakadowego, na podstawie uchway XXI WZ z dnia 16 marca 2008r., oraz uchway XVI NWZ z dnia 27 padziernika 2008r., moe ulec podwyszeniu do kwoty 123.763.528 z. Akcje w podwyszonym kapitale zakadowym BRE Banku SA bd w caoci opacone. -- 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: Non-SMS-managed LOGR offload data sets
1. No. 2. No. What configuration do you have in mind here? You can't have SMS dasd in 2 SMS's, non-SMS dasd is in no SMS at all. What is being 'shared' then? We now have truly split our sysplexes, but we had issues with LOGR datasets when our 2 sysplexes shared the same Dasd with 1 SMS configuration. Kees. Barbara Nitz nitz-...@gmx.net wrote in message news:listserv%201004070348324047.0...@bama.ua.edu... Unscientific survey: How many of you use truly non-SMS-managed LOGR datasets? As in: Using the two model data sets and an IEFDB401 exit that specifies the DALLIKE text unit? How many of you 'share' a pool of DASD (for LOGR data sets) in two SMSs? (Don't ask me why I am asking.) 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 For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286 -- 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: Non-SMS-managed LOGR offload data sets
2. No. What configuration do you have in mind here? You can't have SMS dasd in 2 SMS's, non-SMS dasd is in no SMS at all. What is being 'shared' then? We now have truly split our sysplexes, but we had issues with LOGR datasets when our 2 sysplexes shared the same Dasd with 1 SMS configuration. Didn't I say not to ask? :-) Yes, I know I am told that I cannot have SMS managed DASD in two SMSs. Check another of my rants (I believe last year in conjunction with a question about sysplex setup), to which Mark replied: But it works fine for our dump pool (shared across SMSplexes and SYSPLEXes) and LOGR pool (obviously sysplex in scope, but shared across SMSplexes). So that means in my book that SMS-managed DASD *can* be shared between two SMSs. Not recommended, probably not really supported, but there we go. What I need to have accessible from all systems in the sysplex (share) is a number of volumes that can contain LOGR offload data sets from two subplexes that otherwise know nothing about it each other (in theory). I am also told that it is 'too much work' to make it one SMS config for the full sysplex. And I cannot validate that statement - not my area. 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
Re: Non-SMS-managed LOGR offload data sets
Barbara Nitz nitz-...@gmx.net wrote in message news:listserv%201004070427419325.0...@bama.ua.edu... 2. No. What configuration do you have in mind here? You can't have SMS dasd in 2 SMS's, non-SMS dasd is in no SMS at all. What is being 'shared' then? We now have truly split our sysplexes, but we had issues with LOGR datasets when our 2 sysplexes shared the same Dasd with 1 SMS configuration. Didn't I say not to ask? :-) Yes, I know I am told that I cannot have SMS managed DASD in two SMSs. Check another of my rants (I believe last year in conjunction with a question about sysplex setup), to which Mark replied: But it works fine for our dump pool (shared across SMSplexes and SYSPLEXes) and LOGR pool (obviously sysplex in scope, but shared across SMSplexes). So that means in my book that SMS-managed DASD *can* be shared between two SMSs. Not recommended, probably not really supported, but there we go. What I need to have accessible from all systems in the sysplex (share) is a number of volumes that can contain LOGR offload data sets from two subplexes that otherwise know nothing about it each other (in theory). I am also told that it is 'too much work' to make it one SMS config for the full sysplex. And I cannot validate that statement - not my area. Regards, Barbara Saying don't ask, is asking for being asked ;-) 'too much work' can be anyting, one day or one month. And too much for what? Isn't it the basics of a sysplex that 'all' resources are shared, possibly with some exceptions, but not the other way round? I think you have a legal case for wanting shared dasd resources. It is of course possible that the individual SMS configurations have become so complex that it is a huge job to simplify and merge them. Here I am simplifying our SMS configuration, merging all kinds of subpools, that were some kind of legitimate in the past, but not now anymore. Moreover, I have almost realized mirrored SMS configs, so I can change an SMS configuration on our Testsysplex and move it unmodified to our Prodsysplex, like we do with software. It makes life a lot easier. Kees. For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286 -- 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: Non-SMS-managed LOGR offload data sets
On Wed, 7 Apr 2010 03:48:32 -0500, Barbara Nitz nitz-...@gmx.net wrote: Unscientific survey: How many of you use truly non-SMS-managed LOGR datasets? We still have some. I discovered them in one of our sysplexes a couple of years ago after a space problem (they go to storage volumes). Most of that has been changed to a new HLQ and SMS control, but I guess the person that was working on changing this didn't get everything or get the owners of the logstream to change. As in: Using the two model data sets and an IEFDB401 exit that specifies the DALLIKE text unit? That part, no. How many of you 'share' a pool of DASD (for LOGR data sets) in two SMSs? Yes again. See past posts of mine where I talk about this. Also, see where I talked about sharing dump data sets across multiple SMSplexes and sysplexes (in an MII environment). Mark -- Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS mailto:mzel...@flash.net Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html Systems Programming expert at http://expertanswercenter.techtarget.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
