Re: Consequences of lowering SQA spec
Thanks to evryone who replied on this topic. I changed the SQA allocation on our test system and bounced it last night, but I have decided against doing anything to production. As some people pointed out, it probably won't help anything. Besides, I made a couple of WLM changes with the help of the kind folks at IBM, and I think that made more difference than any measly SQA change could. Thanks, Jon -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Consequences of lowering SQA spec
Hi Jon: Don't know if you tried this but it can be done even if vendor package. Check if BMS maps are above the line. If not re-link to above. Will work with applications below the line. Can save some DSA storage. Regards, Gene -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Consequences of lowering SQA spec
Sam wrote on 06/10/2005 03:17:09 AM: > Hi Jon, > > SQA will overflow into CSA if it gets to 100% and many shops size SQA and > ESQA to overflow deliberately. An 11M PVT seems pretty good to me too. I > can only manage 9M on most of my systems. Remember you get PVT in 1M chunks > so you would have to reduce common below the line enough to get up to 12M. Can't see fiddling with SQA will buy you anything. Some quick maths will determine if you have options in CSA - it's the guy that gets rounded to the next meg boundary. If what you're getting (as CSA) is significantly above what you requested in PARMLIB, you might get lucky just by reducing the request by the appropriate amount. Unlikely given you already get 11M - 10M is the bet I do generally without a *lot* of customization. Other than that, start hacking away at LPA. Lots of luck if you decide on that ... Shane ... -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Consequences of lowering SQA spec
Thanks for the tip. I'll pass it on to our CICS guy. Jon I don't know if it is of any interest, but have you looked at RMODE31 for MacKinney systems? http://www.mackinney.com/products/other/rmode31.htm -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Consequences of lowering SQA spec
> -Original Message- > From: IBM Mainframe Discussion List > [mailto:[EMAIL PROTECTED] On Behalf Of Jon Brock > Sent: Wednesday, October 05, 2005 12:30 PM > To: IBM-MAIN@BAMA.UA.EDU > Subject: Re: Consequences of lowering SQA spec > > > I think you are correct. The problem is that I can't do > anything with the CICS region; I can only manage the OS to > try to get the region as much below-the-line space as > possible. (Our CICS sysprog can't even do a whole lot with > the region -- it is running a purchased app, and he has no > ability to change any of the programs which are currently > running below the line.) > > Jon Jon, I don't know if it is of any interest, but have you looked at RMODE31 for MacKinney systems? http://www.mackinney.com/products/other/rmode31.htm -- John McKown Senior Systems Programmer UICI Insurance Center Information Technology This message (including any attachments) contains confidential information intended for a specific individual and purpose, and its' content is protected by law. If you are not the intended recipient, you should delete this message and are hereby notified that any disclosure, copying, or distribution of this transmission, or taking any action based on it, is strictly prohibited. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Consequences of lowering SQA spec
I think you are correct. The problem is that I can't do anything with the CICS region; I can only manage the OS to try to get the region as much below-the-line space as possible. (Our CICS sysprog can't even do a whole lot with the region -- it is running a purchased app, and he has no ability to change any of the programs which are currently running below the line.) Jon Hello. I believe that the problem is the CICS and not in the SQA area. I suggest to check the following thing: All the transactions and programs must be stored on the line of 16mb, thus we can reduce the value of parameter "DSALIM" and this we unloaded the SQA. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Consequences of lowering SQA spec
Hi Jon, SQA will overflow into CSA if it gets to 100% and many shops size SQA and ESQA to overflow deliberately. An 11M PVT seems pretty good to me too. I can only manage 9M on most of my systems. Remember you get PVT in 1M chunks so you would have to reduce common below the line enough to get up to 12M. Best Regards, Sam Knutson, GEICO Performance and Availability Management mailto:[EMAIL PROTECTED] (office) 301.986.3574 "Think big, act bold, start simple, grow fast..." -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Jon Brock Sent: Wednesday, October 05, 2005 11:55 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Consequences of lowering SQA spec We are trying to fix a problem that one of our CICS regions has with going short-on-storage below the 16MB line. (In the UDSA and CDSA pools, to be exact.) As part of this effort, I am trying to expand the size of our private area. (Insert your Viagra joke here.) At the moment, we have a private area of 11240K, which seems pretty good to me, but I am considering lowering our current specification of SQA in IEASYSxx from 10 to 6. Our system seems to be maxing out at using about 36% of the space currently allocated. What I need to know is what sort of problems I could be letting myself in for if I lower the SQA allocation too much. Will I be up for a week and then start having mysterious file problems or some such? Thanks, Jon <> This email/fax message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution of this email/fax is prohibited. If you are not the intended recipient, please destroy all paper and electronic copies of the original message. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Consequences of lowering SQA spec
> -Original Message- > From: IBM Mainframe Discussion List > [mailto:[EMAIL PROTECTED] On Behalf Of Jon Brock > Sent: Wednesday, October 05, 2005 10:55 AM > To: IBM-MAIN@BAMA.UA.EDU > Subject: Consequences of lowering SQA spec > > > We are trying to fix a problem that one of our CICS regions > has with going short-on-storage below the 16MB line. (In the > UDSA and CDSA pools, to be exact.) As part of this effort, I > am trying to expand the size of our private area. (Insert > your Viagra joke here.) At the moment, we have a private > area of 11240K, which seems pretty good to me, but I am > considering lowering our current specification of SQA in > IEASYSxx from 10 to 6. > > Our system seems to be maxing out at using about 36% of the > space currently allocated. What I need to know is what sort > of problems I could be letting myself in for if I lower the > SQA allocation too much. Will I be up for a week and then > start having mysterious file problems or some such? > > > Thanks, > Jon Uh, how about the possibility of a hard wait code 101? This is reIPL time because you are DEADBEEF. -- John McKown Senior Systems Programmer UICI Insurance Center Information Technology This message (including any attachments) contains confidential information intended for a specific individual and purpose, and its' content is protected by law. If you are not the intended recipient, you should delete this message and are hereby notified that any disclosure, copying, or distribution of this transmission, or taking any action based on it, is strictly prohibited. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Consequences of lowering SQA spec
Hi. Hello. I believe that the problem is the CICS and not in the SQA area. I suggest to check the following thing: All the transactions and programs must be stored on the line of 16mb, thus we can reduce the value of parameter "DSALIM" and this we unloaded the SQA. Saludos a todos, desde Chile. Atte. Alvaro Quintupray B. Ingeniero de Sistemas Nexus S.A. Fon : 420 8149 Fax : 420 8508 -Mensaje original- De: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] nombre de Jon Brock Enviado el: MiƩrcoles, 05 de Octubre de 2005 11:55 Para: IBM-MAIN@BAMA.UA.EDU Asunto: Consequences of lowering SQA spec We are trying to fix a problem that one of our CICS regions has with going short-on-storage below the 16MB line. (In the UDSA and CDSA pools, to be exact.) As part of this effort, I am trying to expand the size of our private area. (Insert your Viagra joke here.) At the moment, we have a private area of 11240K, which seems pretty good to me, but I am considering lowering our current specification of SQA in IEASYSxx from 10 to 6. Our system seems to be maxing out at using about 36% of the space currently allocated. What I need to know is what sort of problems I could be letting myself in for if I lower the SQA allocation too much. Will I be up for a week and then start having mysterious file problems or some such? Thanks, Jon -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] 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 [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Consequences of lowering SQA spec
We are trying to fix a problem that one of our CICS regions has with going short-on-storage below the 16MB line. (In the UDSA and CDSA pools, to be exact.) As part of this effort, I am trying to expand the size of our private area. (Insert your Viagra joke here.) At the moment, we have a private area of 11240K, which seems pretty good to me, but I am considering lowering our current specification of SQA in IEASYSxx from 10 to 6. Our system seems to be maxing out at using about 36% of the space currently allocated. What I need to know is what sort of problems I could be letting myself in for if I lower the SQA allocation too much. Will I be up for a week and then start having mysterious file problems or some such? Thanks, Jon -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html