Re: Expanding eCSA
Thanks Martin, I will follow up with that. I am particularly interested in how the *MASTER* address space uses ePVT. On Thu, Oct 13, 2016 at 1:09 PM, Martin Packer wrote: > Type 30 has 31-bit (and 24-bit FWIW) Allocation numbers for each address > space. DB2 and MQ used to be prime users of 31-Bit (and secondarily CICS > is) but the most modern level of MQ and recentish levels of DB2 chanced > all that. > > And I'm sure you know RMF SMF 78-2 has System-Level virtual storage > numbers - for the commonish areas. > > Cheers, Martin > > Martin Packer, > zChampion, Principal Systems Investigator, > Worldwide Cloud & Systems Performance, IBM > > +44-7802-245-584 > > email: martin_pac...@uk.ibm.com > > Twitter / Facebook IDs: MartinPacker > > Blog: > https://www.ibm.com/developerworks/mydeveloperworks/blogs/MartinPacker > > Podcast Series (With Marna Walle): https://developer.ibm.com/tv/mpt/or > > https://itunes.apple.com/gb/podcast/mainframe-performance- > topics/id1127943573?mt=2 > > > > From: phil yogendran > To: IBM-MAIN@LISTSERV.UA.EDU > Date: 13/10/2016 16:10 > Subject:Expanding eCSA > Sent by:IBM Mainframe Discussion List > > > > Hello All, > > The problem I have is that a few IMS reorg jobs which place a high demand > on eCSA often fail due to insufficient eCSA. > > The current eCSA allocation is 1030M. I would like to try bumping it up to > 1130M or even 1230M. > > My question is how can I determine who would be impacted? Who requires the > most amount of ePRIVATE and what is that number? > > Thanks > > Phil > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > > > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with number > 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Expanding eCSA
Hello All, The problem I have is that a few IMS reorg jobs which place a high demand on eCSA often fail due to insufficient eCSA. The current eCSA allocation is 1030M. I would like to try bumping it up to 1130M or even 1230M. My question is how can I determine who would be impacted? Who requires the most amount of ePRIVATE and what is that number? Thanks Phil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: CSA Shrank in DR
Thank you John. I will review your recommendation and then go back to all our systems and try and implement it ASAP. This is clearly a preventable issue and I don't want to deal with a re-occurrence. On Tue, May 10, 2016 at 9:56 AM, John Eells wrote: > phil yogendran wrote: > >> Thank you very much, all. You have been most helpful. I have run into this >> problem before so I need to spend more time on it. All of your suggestions >> and recommendations will help me get to the bottom of it. Much >> appreciated. >> > > > Some time ago, I wrote a post about setting the CSA specification such > that *specified* CSA ended halfway between 1M boundaries. As *allocated* > CSA is rounded up to the next segment (1M) boundary, this maximizes the > elbow room within which you can make LPA list and IODF changes without > crossing a 1M boundary by accident. Checking once in a while helps keep > you "centered" within the segment. > > If your other DR changes add up to more than 1/2M worth, then perhaps > offsetting from center in the right direction would smooth the transition > without requiring a special DR-only CSA specification and still provide > reasonable elbow room for day-to-day changes. > > You should be able to find my old post in the archives somewhere... > > -- > John Eells > IBM Poughkeepsie > ee...@us.ibm.com > > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: CSA Shrank in DR
Thank you very much, all. You have been most helpful. I have run into this problem before so I need to spend more time on it. All of your suggestions and recommendations will help me get to the bottom of it. Much appreciated. On Fri, May 6, 2016 at 9:15 AM, Peter Relson wrote: > >DR: SQA 988KCSA 3.43M > >Prod:SQA 1.11MCSA 4.28M > > Did you mean that the size of CSA shrank or the amount of CSA being used > shrank? > > I think some of the posts thought it was the former, but the above makes > me think it's the latter. > > The answer for the latter is because you're doing something differently or > your configuration differs. > If you felt like it, you could take an SVC Dump and run the VSMDATA > OWNCOMM report to see what address spaces are using what. > > Peter Relson > z/OS Core Technology Design > > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Storage Increment
Thank you all, your responses were exactly what I was looking for. I did parse the technical guide but was looking for 'storage increment size'. You have shown me that I need to take a much closer look at the manual. FYI, we will have 2 processors with 256G and the other with 128G. So, according to the manual, the increment sizes will be 1G and 512M respectively. Thanks again On Fri, May 6, 2016 at 7:43 AM, Peter X. DeFabritus wrote: > You can also find the storage increment value in field SCCBSAI, or in > field SCCBSAIX if SCCBSAI contains zero. The SCCB is pointed to by the CVT. > > On Thu, 5 May 2016 14:49:04 -0400, phil yogendran > wrote: > > >Hello, > > > >We currently have 3 processors where 2 have a storage increment size of > 256 > >and the 3rd has a storage increment size of 128 defined. > > > >We are going to be migrating to z13's shortly. My question is where do I > >find what the correct storage increment sizes should be? I understand it > is > >specified in the activation profile but how does one determine what the > >increment size should be? Is it based on the hardware model? we're going > to > >two z13-605 and one z13-404 processors. > > > >Thanks, > > > >Phil > > > >-- > >For IBM-MAIN subscribe / signoff / archive access instructions, > >send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Storage Increment
Thanks but where is that documented? How can I tell beforehand that my z13 model 123 will have an increments size of xyz? On Thu, May 5, 2016 at 4:54 PM, Jesse 1 Robinson wrote: > Storage increment is determined by hardware. That's why you see a > difference on your existing boxes. We don't have a z13 in house yet, but > z196 and z12 both show 256 MB in D M=STOR. > > . > . > . > J.O.Skip Robinson > Southern California Edison Company > Electric Dragon Team Paddler > SHARE MVS Program Co-Manager > 323-715-0595 Mobile > 626-302-7535 Office > robin...@sce.com > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of phil yogendran > Sent: Thursday, May 05, 2016 11:49 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: (External):Storage Increment > > Hello, > > We currently have 3 processors where 2 have a storage increment size of > 256 and the 3rd has a storage increment size of 128 defined. > > We are going to be migrating to z13's shortly. My question is where do I > find what the correct storage increment sizes should be? I understand it is > specified in the activation profile but how does one determine what the > increment size should be? Is it based on the hardware model? we're going to > two z13-605 and one z13-404 processors. > > Thanks, > > Phil > > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: CSA Shrank in DR
I did think it was a bigger IODF but in my case SQA in DR has gone down implying a smaller IODF. However, CSA has also gone down. Here's some inform from DR and Prod; DR: SQA 988KCSA 3.43M Prod: SQA 1.11MCSA 4.28M On Thu, May 5, 2016 at 3:25 PM, Bob Rutledge wrote: > On 5/5/2016 3:07 PM, phil yogendran wrote: > >> Hello, >> >> We recently performed a DR exercise and on one of the LPAR's, the CSA was >> smaller by about 800k. Parmlib specification in DR and production were >> identical. The LPAR affected is our designated 'network' box so there are >> no apps or subsystems like CICS or IMS running on it. >> >> Any thoughts on what could make CSA shrink at IPL, particularly when >> parmlib was not changed? The IODF in DR would have been different but I >> can't see that affecting CSA. >> > > If your production CSA size is considerably larger than the specification > in parmlib, the DR IODF could be scarfing more SQA which would affect the > size of CSA. > > Bob > > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
CSA Shrank in DR
Hello, We recently performed a DR exercise and on one of the LPAR's, the CSA was smaller by about 800k. Parmlib specification in DR and production were identical. The LPAR affected is our designated 'network' box so there are no apps or subsystems like CICS or IMS running on it. Any thoughts on what could make CSA shrink at IPL, particularly when parmlib was not changed? The IODF in DR would have been different but I can't see that affecting CSA. Looking forward to your comments. Thanks, Phil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Storage Increment
Hello, We currently have 3 processors where 2 have a storage increment size of 256 and the 3rd has a storage increment size of 128 defined. We are going to be migrating to z13's shortly. My question is where do I find what the correct storage increment sizes should be? I understand it is specified in the activation profile but how does one determine what the increment size should be? Is it based on the hardware model? we're going to two z13-605 and one z13-404 processors. Thanks, Phil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Real Storage Allocation
Thank you all for your replies. My immediate concern was whether there were any issues/problems with over-allocating storage and with your responses, I am confident I can plough ahead. Thanks also for all the tips on how to debug and what to analyze. That's a step for later. Your time and assistance are much appreciated. Regards, Phil On Mon, Feb 15, 2016 at 9:22 AM, John Abell < john.ab...@intnlsoftwareproducts.com> wrote: > As long as your z/OS isn't running under, z/VM like may smaller ISVs, > where LFAREA is not yet supported. > > John T. Abell > Tel:800-295-7608Option 4 > President > International: 1-416-593-5578 Option 4 > E-mail: john.ab...@intnlsoftwareproducts.com > Fax:800-295-7609 > > International: 1-416-593-5579 > > > International Software Products > www.ispinfo.com > > This email may contain confidential and privileged material for the sole > use of the intended recipient(s). Any review, use, retention, distribution > or disclosure by others is strictly prohibited. If you are not the intended > recipient (or authorized to receive on behalf of the named recipient), > please contact the sender by reply email and delete all copies of this > message. Also,email is susceptible to data corruption, interception, > tampering, unauthorized amendment and viruses. We only send and receive > emails on the basis that we are not liable for any such corruption, > interception, tampering, amendment or viruses or any consequence thereof. > > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Ed Jaffe > Sent: Sunday, February 14, 2016 5:05 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Real Storage Allocation > > On 2/14/2016 11:19 AM, Graham Harris wrote: > > Ed Jaffe wrote: > > > > > >> The nice thing about an overabundance of real storage is the ability > >> to > > create a very large LFAREA with plenty of room for 1MB >pageable pages > > and > > -- if you have software that can truly benefit from it (which we > > don't) -- 2G fixed pages. > > > > > > LFAREA does of course only generally hold fixed large pages, although > > it does also handle overflow of PLAREA when that becomes full, which > > maybe what you were thinking. > > LFAREA (Large Frame Area) provides frame space for both fixed and pageable > large pages. We specify: > > LFAREA=7782M, Large frame area > > which is more than enough for our needs. Right after IPL I see some fairly > small numbers: > > D VS,LFAREA > IAR019I 13.56.52 DISPLAY VIRTSTOR 507 > SOURCE = 20 > TOTAL LFAREA = 7782M , 0G > LFAREA AVAILABLE = 7257M , 0G > LFAREA ALLOCATED (1M) = 0M > LFAREA ALLOCATED (4K) = 311M > MAX LFAREA ALLOCATED (1M) = 0M > MAX LFAREA ALLOCATED (4K) = 311M > LFAREA ALLOCATED (PAGEABLE1M) = 214M > MAX LFAREA ALLOCATED (PAGEABLE1M) = 214M > LFAREA ALLOCATED NUMBER OF 2G PAGES = 0 > MAX LFAREA ALLOCATED NUMBER OF 2G PAGES = 0 > > Of course, these numbers grow over time... > > -- > Edward E Jaffe > Phoenix Software International, Inc > 831 Parkview Drive North > El Segundo, CA 90245 > http://www.phoenixsoftware.com/ > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, send email > to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > > --- > This email has been checked for viruses by Avast antivirus software. > https://www.avast.com/antivirus > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Real Storage Allocation
Hello, Is there a downside to over-allocating real storage on an LPAR? We will be upgrading current processors which are tired and soon to be out of service to z13's which will have 4 times the storage we have at present. We don't have any issues with paging or UIC etc. but I feel that on the new processors, I need to make use of most if not all that available storage. Some of my thoughts are; - Will the additional storage be used on an LPAR which already has enough to do it's work. - Is there a way to monitor for 'unused' storage? - If the storage is not used, is there a loss of cycles in an 'overhead' to managing this unused storage? - etc. Your comments will be appreciated. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Coupling Facility Structure Re-sizing
The increases recommended by the CF Sizer is marginal. Our structures in production are generously sized and we have lots of storage in the new CFs so that's not a concern. I will however lookout for messages as suggested. Most of our structures are duplexed. Some like the structure for the IRLM lock are not. I have a note to investigate the product specific doc to understand this better. I also need to check on the performance of CF links as we're going to ICB links now. Thanks for the info. On Fri, Dec 18, 2015 at 12:42 PM, Skip Robinson wrote: > In case you're curious, the parameters 'missing' from your old > definitions were added over the years since the advent of coupling > facility. The new parameters all have defaults such that they do not > actually require specification, but using them may give you better control > over structure sizes. Some additional points: > > -- At any time, the CF Sizer makes recommendations based on the latest > hardware with the latest microcode. Newer hardware or newer microcode > typically requires larger structures to accomplish the same work even with > no changes to the exploiters. > > -- In my experience, CF Sizer makes very generous recommendations. Memory > is cheaper now than ever, but watch out for gratuitous over allocation. > Especially on an external CF, you might be constrained. > > -- Several structures require that you input data to CF Sizer on how busy > you expect the structure to be. For most, this has less to do with the > number of sysplex members than the amount of data the structure has to > handle. This is seldom easy to determine. Make your best SWAG and monitor > the results. > > -- The worst case is when a structure is too small for the exploiter to > initialize. I have not seen this for some time; maybe the big exploiters > have been (re)designed to come up regardless. But watch for messages > indicating that a structure needed more than the specified minimum size at > the outset. > > -- A parameter you did not ask about is DUPLEX. Even if you have only one > box for CF use, I recommend two CF LPARs on that box with duplexing for > relevant structures. Better of course would be two boxes. The best thing > about sysplex is its ability to survive disruptions. Over the years we have > had two CEC failures. In both cases, the second CF allowed all applications > to resume with zero data recovery efforts. Note that some structures do not > require duplexing, notably GRS. If a host dies, so do all of its enqueues. > > > . > . > . > J.O.Skip Robinson > Southern California Edison Company > Electric Dragon Team Paddler > SHARE MVS Program Co-Manager > 323-715-0595 Mobile > jo.skip.robin...@att.net > jo.skip.robin...@gmail.com > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of phil yogendran > Sent: Friday, December 18, 2015 07:39 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: [Bulk] Re: Coupling Facility Structure Re-sizing > > Thank you all for your replies. I will take your suggestions into > consideration going forward. We are in the process of upgrading from z10 - > > z12 -> z13 over the next few months. The CF upgrade is a part of this > project. The CFs are going from 2097/E10 and 2098/E12 to 2817/M15. > > I expect to see better structure response with these changes and will be > surprised to see anything otherwise. Will keep you posted. Thanks again. > > On Fri, Dec 18, 2015 at 8:16 AM, Richards, Robert B. < > robert.richa...@opm.gov> wrote: > > > The archives probably have it, but simply put and if IIRC, there was > > an old 9674 being used with z990s. Waiting on CF structure response > > was horrific as compared to the speed of the z990 processor response. > > > > -Original Message- > > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > > On Behalf Of Elardus Engelbrecht > > Sent: Friday, December 18, 2015 7:55 AM > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: Re: Coupling Facility Structure Re-sizing > > > > Richards, Robert B. wrote: > > > > >The last thing you want is for your CFs to be slower than the CPs. > > >BTDTGTS > > > > Ouch. Could you be kind to tell us about it? Are there any manuals > > stating that trouble? Any configuration changes to avoid? Or is it > > about the sizes or quantity of LPARs involved? > > > > TIA! > > > > Groete / Greetings > > Elardus Engelbrecht > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Coupling Facility Structure Re-sizing
Thank you all for your replies. I will take your suggestions into consideration going forward. We are in the process of upgrading from z10 - > z12 -> z13 over the next few months. The CF upgrade is a part of this project. The CFs are going from 2097/E10 and 2098/E12 to 2817/M15. I expect to see better structure response with these changes and will be surprised to see anything otherwise. Will keep you posted. Thanks again. On Fri, Dec 18, 2015 at 8:16 AM, Richards, Robert B. < robert.richa...@opm.gov> wrote: > The archives probably have it, but simply put and if IIRC, there was an > old 9674 being used with z990s. Waiting on CF structure response was > horrific as compared to the speed of the z990 processor response. > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Elardus Engelbrecht > Sent: Friday, December 18, 2015 7:55 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Coupling Facility Structure Re-sizing > > Richards, Robert B. wrote: > > >The last thing you want is for your CFs to be slower than the CPs. > >BTDTGTS > > Ouch. Could you be kind to tell us about it? Are there any manuals stating > that trouble? Any configuration changes to avoid? Or is it about the sizes > or quantity of LPARs involved? > > TIA! > > Groete / Greetings > Elardus Engelbrecht > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, send email > to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Coupling Facility Structure Re-sizing
Hello, I am in the middle of attempting to go from internal to external CFs. I ran the sizer tool and have the info for the new sizes. However, the INITSIZE and MINSIZE values have me challenged. For most structures, the current allocation doesn't specify a value for either parameter or the specified value appears to be a poor choice. For instance, the book says that SIZE should be no more than 1.5 - 2.0 times INITSIZE but we have some where SIZE is 30 times INITSIZE. My questions are; 1) Should INITSIZE and MINSIZE always be specified? 2) Are all structures 'eligible' to be defined with these parameters? 3) Besides the ratio specified above, are their any guidelines for the definitions? 4) The sizer tool is based on current allocation which may not be ideal. Is there a way to confirm if I have the best fit? 5) Besides the manual "Setting up a Sysplex" is there more doc where I can find additional info? Any suggestions or thoughts will be appreciated. Thanks. Phil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: WLM and Dispatching Priority
True, RMF is SYSSTC. Clearly there's more faith and confidence here. On Thu, Nov 26, 2015 at 1:39 PM, ITURIEL DO NASCIMENTO NETO < 4254.itur...@bradesco.com.br> wrote: > You were talking about your monitors, that were using an importance 1 SC > instead of SYSSTC. And what about RMF ? RMF must be SYSSTC too. > > Atenciosamente / Regards / Saludos > > BANCO BRADESCO S.A. > 4250 / DPCD Engenharia de Software > Sistemas Operacionais Mainframes > Ituriel do Nascimento Neto > Tel: +55 11 3684-2177 R: 42177 3-1404 > Fax: +55 11 3684-4427 > > > > > Banco Bradesco. > Patrocinador oficial dos Jogos Olímpicos e Paralímpicos Rio 2016. > > -Mensagem original- > De: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] Em > nome de phil yogendran > Enviada em: quinta-feira, 26 de novembro de 2015 14:53 > Para: IBM-MAIN@LISTSERV.UA.EDU > Assunto: Re: WLM and Dispatching Priority > > Thank you all for your response and advise. My only reservation is that > SYSVIEW, at times, tends to be heavy-footed and causes the system to > 'pause'. This is only because of the data we capture at periodic intervals. > Anyway, that's for me to investigate further and fix. > > Thanks, again, > > > On Thu, Nov 26, 2015 at 11:16 AM, Ted MacNEIL wrote: > > > Put monitors in SYSSTC. > > This gives them the second highest DP in the system. You cannot > completely > > control the DP in Service Classes. > > > > - > > -teD > > - > > Original Message > > From: phil yogendran > > Sent: Thursday, November 26, 2015 11:02 > > To: IBM-MAIN@LISTSERV.UA.EDU > > Reply To: IBM Mainframe Discussion List > > Subject: WLM and Dispatching Priority > > > > Hello All, > > > > I need some assistance with being able to get a proper DP assigned to a > set > > of tasks. The problem is this; > > > > I have 2 tasks, SYSVIEW and CICSLOGR and many CICS tasks. CICSLOGR is a > > subtask attached by SYSVIEW. > > > > In WLM, SYSVIEW is set to a service class of 'monitor' with an importance > > of 1 and velocity of 75. > > > > The CICS regions are set to a service class of 'CICSA' which has an > > importance of 1 and velocity goal of 65. > > > > However, what I see is that the CICS regions run at a DP of F6 and > SYSVIEW > > is at F4. > > > > How can I make sure that SYSVIEW and CICSLOGR run at a higher DP? I'm on > > z/OS 1.13 and in a sysplex environment. > > > > Looking forward to your response. Thanks. > > > > -- > > For IBM-MAIN subscribe / signoff / archive access instructions, > > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > > > -- > > For IBM-MAIN subscribe / signoff / archive access instructions, > > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > AVISO LEGAL ...Esta mensagem é destinada exclusivamente para a(s) > pessoa(s) a quem é dirigida, podendo conter informação confidencial e/ou > legalmente privilegiada. Se você não for destinatário desta mensagem, desde > já fica notificado de abster-se a divulgar, copiar, distribuir, examinar > ou, de qualquer forma, utilizar a informação contida nesta mensagem, por > ser ilegal. Caso você tenha recebido esta mensagem por engano, pedimos que > nos retorne este E-Mail, promovendo, desde logo, a eliminação do seu > conteúdo em sua base de dados, registros ou sistema de controle. Fica > desprovida de eficácia e validade a mensagem que contiver vínculos > obrigacionais, expedida por quem não detenha poderes de representação. > LEGAL ADVICE...This message is exclusively destined for the people to > whom it is directed, and it can bear private and/or legally exceptional > information. If you are not addressee of this message, since now you are > advised to not release, copy, distribute, check or, otherwise, use the > information contained in this message, because it is illegal. If you > received this message by mistake, we ask you to return this email, making > possible, as soon as possible, the elimination of its contents of your > database, registrations or controls system. The message that bears any > mandatory links, issued by someone who has no representation powers, shall > be null or void. > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: WLM and Dispatching Priority
Thank you all for your response and advise. My only reservation is that SYSVIEW, at times, tends to be heavy-footed and causes the system to 'pause'. This is only because of the data we capture at periodic intervals. Anyway, that's for me to investigate further and fix. Thanks, again, On Thu, Nov 26, 2015 at 11:16 AM, Ted MacNEIL wrote: > Put monitors in SYSSTC. > This gives them the second highest DP in the system. You cannot completely > control the DP in Service Classes. > > - > -teD > - > Original Message > From: phil yogendran > Sent: Thursday, November 26, 2015 11:02 > To: IBM-MAIN@LISTSERV.UA.EDU > Reply To: IBM Mainframe Discussion List > Subject: WLM and Dispatching Priority > > Hello All, > > I need some assistance with being able to get a proper DP assigned to a set > of tasks. The problem is this; > > I have 2 tasks, SYSVIEW and CICSLOGR and many CICS tasks. CICSLOGR is a > subtask attached by SYSVIEW. > > In WLM, SYSVIEW is set to a service class of 'monitor' with an importance > of 1 and velocity of 75. > > The CICS regions are set to a service class of 'CICSA' which has an > importance of 1 and velocity goal of 65. > > However, what I see is that the CICS regions run at a DP of F6 and SYSVIEW > is at F4. > > How can I make sure that SYSVIEW and CICSLOGR run at a higher DP? I'm on > z/OS 1.13 and in a sysplex environment. > > Looking forward to your response. Thanks. > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
WLM and Dispatching Priority
Hello All, I need some assistance with being able to get a proper DP assigned to a set of tasks. The problem is this; I have 2 tasks, SYSVIEW and CICSLOGR and many CICS tasks. CICSLOGR is a subtask attached by SYSVIEW. In WLM, SYSVIEW is set to a service class of 'monitor' with an importance of 1 and velocity of 75. The CICS regions are set to a service class of 'CICSA' which has an importance of 1 and velocity goal of 65. However, what I see is that the CICS regions run at a DP of F6 and SYSVIEW is at F4. How can I make sure that SYSVIEW and CICSLOGR run at a higher DP? I'm on z/OS 1.13 and in a sysplex environment. Looking forward to your response. Thanks. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Smaller Private Area in DR
Hello All, I have been reviewing the data for private and am puzzled with what I see. The data from PROD taken with SYSVIEW is as follows; RegionStart EndLength Bytes Used RONUC _00FE3000 _00FF _0001D000 116K 113K RWNUC_00FD4000 _00FE2FFF _F000 60K55.9K SQA _00EB5000 _00FD3FFF _0011F000 1.12M 502K PLPA_00C98000 _00EB4FFF _0021D000 2.11M 2.11M FLPA_ _ _ 0 0 MLPA_ _ _ 0 0 CSA _0080 _00C97FFF _00498000 4.59M 791K PVT _6000 _007F _007FA000 7.98M 655K RCT _2000 _5FFF _4000 16Kn/a PSA _ _1FFF _2000 8Kn/a >From Parmlib; CSA=(4100K,150M) SQA=(384K,24M) According to this map, the system has allocated about 200+K more for SQA and about 500K more for CSA. Everything aligns on the 8M boundary and this is fine in production. However, in DR we lost a meg and private dropped to 7M. Given that more than half of SQA is unused and only a fraction of CSA is used, my expectation is that there was ample storage to accommodate a bigger I/O configuration and still stay with the 8M boundary. The big assumption is that my problem in DR was the I/O configuration. Whatever increased in DR had to be pretty large is my thinking. Many of you stated how important it was to define CSA to fall around a 1/2M boundary. Our CSA allocation of 4.1M takes common to around the 7.33M mark leaving private with 8M. How does this look to you? The CSA allocation seems to be unnecessarily large and I can't explain it as I am new to the shop. That however is a separate issue. Your comments are much appreciated. Thanks On Mon, Aug 31, 2015 at 1:34 PM, J O Skip Robinson wrote: > I think a lot of shops use this strategy for managing the common/private > boundary. > > 1. Look at a running system. > 2. Verify that the system is happy with defined CSA/SQA. > 3. Verify that the private area is 'satisfactory', i.e. not too small nor > needlessly large. > 4. Calculate the contribution to CSA/SQA that IEASYSxx values have added > to the z/OS requirement. > 5. Adjust the IEASYSxx values to the midpoint of the final 1M portion. > > Since the user specification will tweak the 1M boundary placement, we aim > to maximize any possible fluctuation that will preserve the private area > sweet spot. That is, allow for 512K up or down in z/OS calculation without > changing private area, which many (most?) systems are most sensitive to. > OP's problem after all is to explain a 1M drop in private, not a change to > common. > > BTW I looked at my VSM health checks but did not see this information > displayed starkly. > > . > . > . > J.O.Skip Robinson > Southern California Edison Company > Electric Dragon Team Paddler > SHARE MVS Program Co-Manager > 626-302-7535 Office > 323-715-0595 Mobile > jo.skip.robin...@sce.com > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Peter Relson > Sent: Saturday, August 29, 2015 6:55 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Smaller Private Area in DR > > > The real question is when the COMMON/PRIVATE boundary gets set. IODF must > be read and digested very early in IPL, certainly before SYS1.PARMLIB is > opened. By the time IEASYSxx is processed, do below-the-line UCBs figure > into the boundary calculation? > > > > It works something like this: > > -- Load the nucleus. Thus we have a definition for where that starts and > ends. > -- Build things such as UCB's that require common storage (think of that > as initial SQA) > -- Read system parameters to see the definitions of SQA, CSA > -- Now determine the boundary of SQA (multiple of 64K?) based on the > initial SQA and the SQA specification > -- Now build LPA > -- Use the LPA boundaries and the CSA size to define the CSA boundaries > (1M multiple?) > -- That is when the Common/Private boundary is set > > Any differences in the "earlier" areas can affect the Common/Private > boundary. > > I seem to recall (but might be wrong) that one of the VSM health checks > reports on how close you are to the point where you will lose 1M of private. > > Peter Relson > z/OS Core Technology Design > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Smaller Private Area in DR
Thanks Peter and John. I am looking into whether SMF data from DR is available. Will post on the list of I find anything new. On Fri, Aug 28, 2015 at 9:56 AM, John Eells wrote: > rel...@us.ibm.com (Peter Relson) wrote: > > >> A pair of dumps (one on each system) seems like the right way to diagnose >> this (rather than making intelligent guesses), in order to be able to view >> things like the boundaries and sizes of CSA, LPA, SQA, and the nucleus >> (most of the data is either in the CVT or the GDA). >> > > Also, if you have RMF available, the Virtual Storage Activity Report shows > the starting address and size of common storage areas under the "Static > Storage Map" heading. (The RMF SMF records might be available even if the > DR system is not currently available...just a thought.) > > -- > John Eells > z/OS Technical Marketing > IBM Poughkeepsie > ee...@us.ibm.com > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Smaller Private Area in DR
All, Thank you very much for all the informative comments. I am familiar with the layout of an address space but the refresher is always welcome. Thanks John, the comments about CSA allocation was particularly instructive. As many of you pointed out, I too now believe that changes to the I/O configuration is the likely culprit as DR was at a vendor site. I will do more work to figure out how we can accommodate these configuration changes in future. Thanks again. On Thu, Aug 27, 2015 at 6:14 PM, J O Skip Robinson wrote: > I did not see in this thread any mention of who owns the DR environment. > We own and manage our own DR environment, so we know exactly what's there. > If OP's DR is in the hands of a vendor, then the I/O configuration may > differ as others have indicated. In particular, UCB location can make a big > difference if there are lots of devices. I believe that LOCANY defaults to > NO. Unless specifically coded for above-the-line location, UCBs in a large > configuration can take up a lot of space below 16M. If as others have > suggested the specified CSA value is already close to a megabyte boundary, > a lot of unexpected UCBs could cause COMMON to encroach on PRIVATE. > > . > . > . > J.O.Skip Robinson > Southern California Edison Company > Electric Dragon Team Paddler > SHARE MVS Program Co-Manager > 626-302-7535 Office > 323-715-0595 Mobile > jo.skip.robin...@sce.com > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Ed Finnell > Sent: Thursday, August 27, 2015 2:09 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Smaller Private Area in DR > > A "pocket protector's" worth of Display Commands. > > > http://idcp.marist.edu/pdfs/ztidbitz/MVS%20CONSOLE%20COMMANDS.pdf > > > In a message dated 8/27/2015 3:55:31 P.M. Central Daylight Time, > ee...@us.ibm.com writes: > > Of course, you want to recheck the end of the specification and the next > 1M boundary once in a while, and (continue to!) monitor used CSA to make > sure overt action (such as reducing what's in the LPA list) is not needed > to pull the starting address back far enough to preserve CSA free space. > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Smaller Private Area in DR
Thanks all for the responses. I'm referring to private below the line. Unfortunately, there's no dump or map of storage to do any meaningful debugging. The obvious reason is that something was added somewhere for private to drop 1M. I'm aware it changes in 1M chunks. However, 'nothing changed' is what I'm told. Mark, can you elaborate please? Would that be in the IODF that was picked up in DR? Thanks On Thu, Aug 27, 2015 at 3:01 PM, Ed Finnell < 000248cce9f3-dmarc-requ...@listserv.ua.edu> wrote: > Have to examine all the parts. CSA, ECSA, etc that take away from private. > Something like Mark's IPLINFO is a starter or the PRIVAT mapper in IVP lib > is another choice. > > > In a message dated 8/27/2015 1:47:44 P.M. Central Daylight Time, > mark.jac...@custserv.com writes: > > Might be related to the number of devices defined to the environment. > Are you talking about above or below private? > > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
