Re: Region size
In AANLkTikFnXd-t=uzqzrcspu5zgunr-rc2eblvwyjy...@mail.gmail.com, on 03/26/2011 at 09:53 PM, Mike Schwab mike.a.sch...@gmail.com said: It was 15% used of 6 Mod 3 paging packs, 9 Mod 9 sort work volumes. The working set is the number of page frames required in real storage, not the number in AUX. While you certainly need enough AUX to back up all of your virtual memory, the performance is tied into the working set size, the amount of free real storage and the configuration of the locals. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- 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: Region size
Shmuel Metz (Seymour J.) wrote: In 4d8bb1eb.6000...@dino-software.com, on 03/24/2011 at 02:04 PM, Dave Roeser dave.roe...@dino-software.com said: Anyway, he wishes to know if this is an in-storage sort or is it to use external media? What's the working set? If the data are larger than the working set then he will see paging, and will need to analyze the tradeoffs between paging I/O and explicit I/O to external media. He might need to tweak his reference pattern to get good performance. -- In my experience, which is admittedly not infinite, I've learned that allowing SORT a reasonable region size and using the SORTWKxx files hs a less deleterious effect on overall system performance than simply giving SORT a huge region and just letting it page. Let us always remember that paging is bad. It is non-productive I/O and cycles spent that produce no useful work, other than shuffling things around and impacting everything in the system. At least DFSORT can determine when it's necessary to do I/O to SORTWKxx files and schedule it such that it has least impact on the task at hand, as well as other tasks within the system. Rick -- 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: Region size
With memory limits we have to remember that supports is different from performs well up to. As my audiences will know I talk about the work z/OS and Hardware Development did to make memory scale well. Martin Martin Packer, Mainframe Performance Consultant, zChampion Worldwide Banking Center of Excellence, IBM +44-7802-245-584 email: martin_pac...@uk.ibm.com Twitter / Facebook IDs: MartinPacker Blog: https://www.ibm.com/developerworks/mydeveloperworks/blogs/MartinPacker 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...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Region size
In 00e601cbea4a$35625f70$a0271e50$@hawkins1...@sbcglobal.net, on 03/24/2011 at 10:37 AM, Ron Hawkins ron.hawkins1...@sbcglobal.net said: Otherwise AFAIK DFSORT will have pages stolen and demand page with or without block paging just like any other batch job. I never said otherwise. I'm sure you know all this already, so what's your point? Google for PGSER, then read my message again. My point was that using data spaces does not automatically mean demand paging, and I was asking what DFSORT does or doesn't do to manage its data spaces. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- 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: Region size
In 4d8bb1eb.6000...@dino-software.com, on 03/24/2011 at 02:04 PM, Dave Roeser dave.roe...@dino-software.com said: Anyway, he wishes to know if this is an in-storage sort or is it to use external media? What's the working set? If the data are larger than the working set then he will see paging, and will need to analyze the tradeoffs between paging I/O and explicit I/O to external media. He might need to tweak his reference pattern to get good performance. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- 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: Region size
Shmuel, Google for PGSER, then read my message again. My point was that using data spaces does not automatically mean demand paging, and I was asking what DFSORT does or doesn't do to manage its data spaces. I'd guess that they are using DSPSERV to load dataspace pages and avoid serial demand paging, but I not know. If I had time I could force dataspace sorts and dataspace paging for sort and try and figure it out from the behavior but that won't happen in the next few days. If this sort of paging is unavoidable then perhaps one should look at using HDS Cache Residency Manager or EMC's Permacahe for the Local Page datasets. I don't thing IBM have an equivalent, and Flash Drives are much slower than these locked cache methods. Ron -- 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: Region size
It was 15% used of 6 Mod 3 paging packs, 9 Mod 9 sort work volumes. On Sat, Mar 26, 2011 at 7:23 PM, Shmuel Metz (Seymour J.) shmuel+ibm-m...@patriot.net wrote: In 4d8bb1eb.6000...@dino-software.com, on 03/24/2011 at 02:04 PM, Dave Roeser dave.roe...@dino-software.com said: Anyway, he wishes to know if this is an in-storage sort or is it to use external media? What's the working set? If the data are larger than the working set then he will see paging, and will need to analyze the tradeoffs between paging I/O and explicit I/O to external media. He might need to tweak his reference pattern to get good performance. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- 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 -- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all? -- 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: Region size
Jim Mulder pisze: IBM Mainframe Discussion List IBM-MAIN@bama.ua.edu wrote on 03/24/2011 11:04:20 AM: Another reason why it was a joke is because a V=R address space with REGION=150GB would imply that the system has at least 150GB of central storage, which, AFAIK, has not yet happened in the z/OS world. And, if the system has less than that, then the job will never start. z/OS 1.8 supports up to 4TB of central storage. Prior to z/OS 1.8, the limit was 128GB. AFAIK it's hard to buy a machine with 4TB of memory, especially those compatible with z/OS. ;-) Not to mention, the thread comes from - let's say it diplomatically - irrational user request. -- 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 16.07.2010 r. kapita zakadowy BRE Banku SA (w caoci wpacony) wynosi 168.248.328 zotych. -- 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: Region size
-Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Rick Fochtman Sent: Thursday, March 24, 2011 3:16 PM To: IBM-MAIN@bama.ua.edu Subject: Re: Region size ---snip- - I am looking forward to hearing the results of their bubble sort. Cold, very cold. But I wouldn't bet against it. And yes, cruel as it is it's still funny. Thanks. unsnip-- I'd give a case of your favorite beer for an Assember implementation of Knuth's Balanced Binary Tree sort, as detailed in his Sorting and Searching volume. I wish he'd finish that series (The Art of Computer Programming). After a stellar start, it seems to have died on the vine. Rick Have you gotten his latest? It is Volume 4A. From reading the prefix, that one volume may require multiple issues (4B, 4C, ...). And 4A is the same size as all of the others. Heavy enough to press pants with. Wish it were an e-book! -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * john.mck...@healthmarkets.com * www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM -- 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: Region size
-Original Message- From: IBM Mainframe Discussion List On Behalf Of Rick Fochtman [ snip ] unsnip -- I'd give a case of your favorite beer for an Assember implementation of Knuth's Balanced Binary Tree sort, as detailed in his Sorting and Searching volume. I wish he'd finish that series (The Art of Computer Programming). After a stellar start, it seems to have died on the vine. Volume 4A became available recently: http://www.amazon.com/s/ref=nb_sb_noss?url=search-alias%3Dapsfield-keyw ords=%22the+art+of+computer+programming%22x=16y=19 or http://tinyurl.com/4hflhxz -jc- -- 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: Region size
If z/OS now supports 4TB of central storage, then IBM has presumably tested it somewhere. Which means it's possible to have 4TB really there. Bill Fairchild Rocket Software -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of R.S. Sent: Friday, March 25, 2011 2:42 AM To: IBM-MAIN@bama.ua.edu Subject: Re: Region size Jim Mulder pisze: IBM Mainframe Discussion List IBM-MAIN@bama.ua.edu wrote on 03/24/2011 11:04:20 AM: Another reason why it was a joke is because a V=R address space with REGION=150GB would imply that the system has at least 150GB of central storage, which, AFAIK, has not yet happened in the z/OS world. And, if the system has less than that, then the job will never start. z/OS 1.8 supports up to 4TB of central storage. Prior to z/OS 1.8, the limit was 128GB. AFAIK it's hard to buy a machine with 4TB of memory, especially those compatible with z/OS. ;-) Not to mention, the thread comes from - let's say it diplomatically - irrational user request. -- 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 16.07.2010 r. kapita zakadowy BRE Banku SA (w caoci wpacony) wynosi 168.248.328 zotych. -- 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: Region size
On Fri, 25 Mar 2011 08:41:39 +0100, R.S. wrote: Jim Mulder pisze: IBM Mainframe Discussion List IBM-MAIN@bama.ua.edu wrote on 03/24/2011 11:04:20 AM: z/OS 1.8 supports up to 4TB of central storage. Prior to z/OS 1.8, the limit was 128GB. AFAIK it's hard to buy a machine with 4TB of memory, especially those compatible with z/OS. ;-) Right. You can only get 3056 GB on a zEnterprise 196. -- Tom Marchant -- 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: Region size
IBM Mainframe Discussion List IBM-MAIN@bama.ua.edu wrote on 03/25/2011 12:16:23 PM: If z/OS now supports 4TB of central storage, then IBM has presumably tested it somewhere. Which means it's possible to have 4TB really there. Bill Fairchild Rocket Software Jim Mulder pisze: IBM Mainframe Discussion List IBM-MAIN@bama.ua.edu wrote on 03/24/2011 11:04:20 AM: Another reason why it was a joke is because a V=R address space with REGION=150GB would imply that the system has at least 150GB of central storage, which, AFAIK, has not yet happened in the z/OS world. And, if the system has less than that, then the job will never start. z/OS 1.8 supports up to 4TB of central storage. Prior to z/OS 1.8, the limit was 128GB. I will try to be a bit more clear. The design point of z/OS 1.8 is to support up to 4TB of central storage. A z196 can have up to 3TB of central storage installed, with up to 1TB in a single logical partition. So we have not tested z/OS with anything larger than 1TB at this time. Jim Mulder z/OS System Test IBM Corp. Poughkeepsie, NY -- 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: Region size
In-storage. Sorting IDMS alternate indices. 64-bit storage optional but 31-bit storage required. Rick Dave Roeser wrote: Rick, One of my developers and friend, Dave Loveluck, has written a version in C and C++. He has written an assembler version of a balanced Red-Green tree (ok it is Red Black ..). He says writing an assembler version of a balanced binary tree sort would not be difficult - although I need to find out where all this spare time is coming from...hmmm Anyway, he wishes to know if this is an in-storage sort or is it to use external media? Regards, Dave Dave Roeser Product Manager DINO-Software Corporation http://www.dino-software.com On 3/24/2011 1:16 PM, Rick Fochtman wrote: ---snip-- I am looking forward to hearing the results of their bubble sort. Cold, very cold. But I wouldn't bet against it. And yes, cruel as it is it's still funny. Thanks. unsnip-- I'd give a case of your favorite beer for an Assember implementation of Knuth's Balanced Binary Tree sort, as detailed in his Sorting and Searching volume. I wish he'd finish that series (The Art of Computer Programming). After a stellar start, it seems to have died on the vine. Rick -- 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 -- 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: Region size
W dniu 2011-03-25 17:16, Bill Fairchild pisze: If z/OS now supports 4TB of central storage, then IBM has presumably tested it somewhere. Which means it's possible to have 4TB really there. Well... No. I remember Novell Netware v3 or v4. It was 32-bit OS, so Novell claimed it support up to 4GB RAM. In 1990 (premiere of 3.x) there was no 386 machine supporting so much memory. I would say more: there were NEVER 386 machine commercially available with 4GB of RAM. However around 1999 Novell ...changed official information - they supported only 3,25GB. Possible reason: they finally did the tests and found some limitation. In z/OS there is some barrier which is set by designers at 4TB. So, they are sure of the limitation, because they did set it. And there is no other KNOWN limitation. BTW: To Tom - yes, z196 supports up to 3TB, but AFAIK single LPAR is able to support up to 1TB (as in z10). -- 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 16.07.2010 r. kapita zakadowy BRE Banku SA (w caoci wpacony) wynosi 168.248.328 zotych. -- 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: Region size
In listserv%201103230921059304.0...@bama.ua.edu, on 03/23/2011 at 09:21 AM, Elardus Engelbrecht elardus.engelbre...@sita.co.za said: Even when searching for groups, I found useless links for groups unrelated to 'computer'. You should have also found highly useful links for groups unrelated to computers, although these days people use software to assist that work. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- 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: Region size
In 007001cbe921$d9fc8a30$8df59e90$@hawkins1...@sbcglobal.net, on 03/22/2011 at 11:16 PM, Ron Hawkins ron.hawkins1...@sbcglobal.net said: ROTFLMAO! They thing demand paging will be faster than CFW to SORTWK? Oh the pain... Does DFSORT use demand paging, or does it explictly request page-ins ahead of time? Similarly, does it wait for page stealing or does it release pages itself? -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- 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: Region size
In 77142d37c0c3c34da0d7b1da7d7ca3430882a...@nwt-s-mbx2.rocketsoftware.com, on 03/23/2011 at 01:48 PM, Bill Fairchild bi...@mainstar.com said: I am looking forward to hearing the results of their bubble sort. Cold, very cold. But I wouldn't bet against it. And yes, cruel as it is it's still funny. Thanks. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- 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: Region size
In bb968e7840462d4bbab03e9019fdca7e88598...@surfsdvmp35.cnasurety.net, on 03/23/2011 at 02:18 PM, Givens, Dennis W. dennis.giv...@cnasurety.com said: You will want to ensure that your system can support V=R. It's a joke, son. AFAIK there has never been V=R support above the line, other than DAT-off code in the Nucleus, and even that I'm not sure about. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- 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: Region size
Another reason why it was a joke is because a V=R address space with REGION=150GB would imply that the system has at least 150GB of central storage, which, AFAIK, has not yet happened in the z/OS world. And, if the system has less than that, then the job will never start. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Shmuel Metz (Seymour J.) Sent: Thursday, March 24, 2011 8:42 AM To: IBM-MAIN@bama.ua.edu Subject: Re: Region size In bb968e7840462d4bbab03e9019fdca7e88598...@surfsdvmp35.cnasurety.net, on 03/23/2011 at 02:18 PM, Givens, Dennis W. dennis.giv...@cnasurety.com said: You will want to ensure that your system can support V=R. It's a joke, son. AFAIK there has never been V=R support above the line, other than DAT-off code in the Nucleus, and even that I'm not sure about. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- 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: Region size
Shmuel, Blockset may resemble paging IO in the way it would track switch over a CYL as it laid down blocks, but that's probably not an advantage any more with cache all storage and CKD encapsulation into FBA. This behavior is one reason why the cache hit rate for Local Page datasets is somewhat poor, but I haven't observed how block paging behaves in polluted or small cache. DFSORT's IO to the SORTWK are explicitly requested in response to DFSORT deciding it has exhausted its own memory. At startup it attempts to, and usually succeeds in selecting memory boundaries that avoid paging, using the SORTWK as the memory overflow area. This could be viewed as DFSORT doing its own paging, or at least its own memory management. Otherwise AFAIK DFSORT will have pages stolen and demand page with or without block paging just like any other batch job. I'm sure you know all this already, so what's your point? Ron -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Shmuel Metz (Seymour J.) Sent: Thursday, March 24, 2011 6:33 AM To: IBM-MAIN@bama.ua.edu Subject: Re: [IBM-MAIN] Region size In 007001cbe921$d9fc8a30$8df59e90$@hawkins1...@sbcglobal.net, on 03/22/2011 at 11:16 PM, Ron Hawkins ron.hawkins1...@sbcglobal.net said: ROTFLMAO! They thing demand paging will be faster than CFW to SORTWK? Oh the pain... Does DFSORT use demand paging, or does it explictly request page-ins ahead of time? Similarly, does it wait for page stealing or does it release pages itself? -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- 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: Region size
On Thu, Mar 24, 2011 at 12:37 PM, Ron Hawkins ron.hawkins1...@sbcglobal.net wrote: Shmuel, Blockset may resemble paging IO in the way it would track switch over a CYL as it laid down blocks, but that's probably not an advantage any more with cache all storage and CKD encapsulation into FBA. This behavior is one reason why the cache hit rate for Local Page datasets is somewhat poor, but I haven't observed how block paging behaves in polluted or small cache. DFSORT's IO to the SORTWK are explicitly requested in response to DFSORT deciding it has exhausted its own memory. At startup it attempts to, and usually succeeds in selecting memory boundaries that avoid paging, using the SORTWK as the memory overflow area. This could be viewed as DFSORT doing its own paging, or at least its own memory management. Otherwise AFAIK DFSORT will have pages stolen and demand page with or without block paging just like any other batch job. I'm sure you know all this already, so what's your point? Ron The DB2 people wanting 150GB in paging packs refused to code SORTWK DD statements to force in-core sorts. I have always coded SORTWKs even if they were never needed. -- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all? -- 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: Region size
And I have DFSORT set to to totally ignore whether SORTWK DD statements are coded or not. I use ICEPRM00 in PARMLIB like: JCL, DYNALOC=(SYSDA,31), DYNAUTO=IGNWKDD INV, DYNALOC=(SYSDA,31), TMAXLIM=1000 TSO, DYNALOC=(SYSDA,31) TSOINV, DYNALOC=(SYSDA,31) JCL coders here did not think it was wise to make them determine the SORTWK needed. I think that I agree. -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * john.mck...@healthmarkets.com * www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Mike Schwab Sent: Thursday, March 24, 2011 1:03 PM To: IBM-MAIN@bama.ua.edu Subject: Re: Region size On Thu, Mar 24, 2011 at 12:37 PM, Ron Hawkins ron.hawkins1...@sbcglobal.net wrote: Shmuel, Blockset may resemble paging IO in the way it would track switch over a CYL as it laid down blocks, but that's probably not an advantage any more with cache all storage and CKD encapsulation into FBA. This behavior is one reason why the cache hit rate for Local Page datasets is somewhat poor, but I haven't observed how block paging behaves in polluted or small cache. DFSORT's IO to the SORTWK are explicitly requested in response to DFSORT deciding it has exhausted its own memory. At startup it attempts to, and usually succeeds in selecting memory boundaries that avoid paging, using the SORTWK as the memory overflow area. This could be viewed as DFSORT doing its own paging, or at least its own memory management. Otherwise AFAIK DFSORT will have pages stolen and demand page with or without block paging just like any other batch job. I'm sure you know all this already, so what's your point? Ron The DB2 people wanting 150GB in paging packs refused to code SORTWK DD statements to force in-core sorts. I have always coded SORTWKs even if they were never needed. -- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all? -- 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: Region size
Rick, One of my developers and friend, Dave Loveluck, has written a version in C and C++. He has written an assembler version of a balanced Red-Green tree (ok it is Red Black ..). He says writing an assembler version of a balanced binary tree sort would not be difficult - although I need to find out where all this spare time is coming from...hmmm Anyway, he wishes to know if this is an in-storage sort or is it to use external media? Regards, Dave Dave Roeser Product Manager DINO-Software Corporation http://www.dino-software.com On 3/24/2011 1:16 PM, Rick Fochtman wrote: ---snip-- I am looking forward to hearing the results of their bubble sort. Cold, very cold. But I wouldn't bet against it. And yes, cruel as it is it's still funny. Thanks. unsnip-- I'd give a case of your favorite beer for an Assember implementation of Knuth's Balanced Binary Tree sort, as detailed in his Sorting and Searching volume. I wish he'd finish that series (The Art of Computer Programming). After a stellar start, it seems to have died on the vine. Rick -- 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: Region size
There are plenty of ways to get SORT to do the SORTWK allocations for you. If you've gone thru the work to set it up ... I dislike coding SORTWK DDs if I don't have to. Of course there are also times that they are invaluable. I prefer to only code what is really needed... otherwise you endup with the silly JCL and pet peeves like on http://planetmvs.com/peeves/index.html under IEBCOPY Overdrive. *grin* Rob Schramm On Thu, Mar 24, 2011 at 4:24 PM, Rick Fochtman rfocht...@ync.net wrote: -snip--- The DB2 people wanting 150GB in paging packs refused to code SORTWK DD statements to force in-core sorts. I have always coded SORTWKs even if they were never needed. unsnip-- Sounds like a terminal case of Tunnel Vision to me. How much do they know about z/OS outside DB2? My guess: not much, if anything. The word you seek is DUMB. :-) Rick -- 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 -- Rob Schramm Senior Systems Engineer w: 513.305.6224 -- 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: Region size
---snip-- I am looking forward to hearing the results of their bubble sort. Cold, very cold. But I wouldn't bet against it. And yes, cruel as it is it's still funny. Thanks. unsnip-- I'd give a case of your favorite beer for an Assember implementation of Knuth's Balanced Binary Tree sort, as detailed in his Sorting and Searching volume. I wish he'd finish that series (The Art of Computer Programming). After a stellar start, it seems to have died on the vine. Rick -- 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: Region size
-snip--- The DB2 people wanting 150GB in paging packs refused to code SORTWK DD statements to force in-core sorts. I have always coded SORTWKs even if they were never needed. unsnip-- Sounds like a terminal case of Tunnel Vision to me. How much do they know about z/OS outside DB2? My guess: not much, if anything. The word you seek is DUMB. :-) Rick -- 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: Region size
Rick Fochtman write: I'd give a case of your favorite beer for an Assember implementation of Knuth's Balanced Binary Tree sort, as detailed in his Sorting and Searching volume. I wish he'd finish that series (The Art of Computer Programming). After a stellar start, it seems to have died on the vine. Rick Not sure if this is a whoosh or not. Volume 4 of The Art of Computer Programming came out just a month or two ago. Or perhaps I should say, Volume 4A, since the full 4th volume is being split into at least three sub-volumes due to size. There's a copy sitting on my desk now. Cheers, Allen -- 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: Region size
On Thu, Mar 24, 2011 at 3:24 PM, Rick Fochtman rfocht...@ync.net wrote: -snip--- The DB2 people wanting 150GB in paging packs refused to code SORTWK DD statements to force in-core sorts. I have always coded SORTWKs even if they were never needed. unsnip-- Sounds like a terminal case of Tunnel Vision to me. How much do they know about z/OS outside DB2? My guess: not much, if anything. The word you seek is DUMB. :-) Rick I was considering opening a PMR with the Vendor that the software did not support DASD or TAPE sorts. The next alternative was opening a problem with Human Resources and reporting the personel supplied did not know the difference between 'fastest' and 'only' in vendo documentation. -- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all? -- 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: Region size
IBM Mainframe Discussion List IBM-MAIN@bama.ua.edu wrote on 03/24/2011 09:42:22 AM: You will want to ensure that your system can support V=R. It's a joke, son. AFAIK there has never been V=R support above the line, That is correct. V=R is supported only for private area below 16MB, so 16MB is an upper bound (but not a least upper bound) on the size of a V=R region. other than DAT-off code in the Nucleus, and even that I'm not sure about. The DAT-off nucleus is in contiguous real storage, but it is not virtualized anywhere, and is accessible only via real addresses. Jim Mulder z/OS System Test IBM Corp. Poughkeepsie, NY -- 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: Region size
IBM Mainframe Discussion List IBM-MAIN@bama.ua.edu wrote on 03/24/2011 11:04:20 AM: Another reason why it was a joke is because a V=R address space with REGION=150GB would imply that the system has at least 150GB of central storage, which, AFAIK, has not yet happened in the z/OS world. And, if the system has less than that, then the job will never start. z/OS 1.8 supports up to 4TB of central storage. Prior to z/OS 1.8, the limit was 128GB. Jim Mulder z/OS System Test IBM Corp. Poughkeepsie, NY -- 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: Region size
From: Dave Roeser dave.roe...@dino-software.com To: IBM-MAIN@bama.ua.edu Sent: Thu, March 24, 2011 4:04:43 PM Subject: Re: Region size Rick, One of my developers and friend, Dave Loveluck, has written a version in C and C++. He has written an assembler version of a balanced Red-Green tree (ok it is Red Black ..). He says writing an assembler version of a balanced binary tree sort would not be difficult - although I need to find out where all this spare time is coming from...hmmm Anyway, he wishes to know if this is an in-storage sort or is it to use external media? Regards, Dave D Dave: When I was a newbie sysprog hmmm many years ago. Our application people came up with their own sort. I guess it worked fine for them but we did notice a bump in cpu resources that it needed. It probably would not have been if it had stayed that way.. one application program. Then it started to pop up all over their system. Cpu resources were really tight and we really had no place to grow. Another CPU was not an answer we were already an MP shop. I got orders to investigate and had a couple of meetings with the not to friendly programmers. AFter getting rebuffed I went over their heads and only then did I get some co-operation. I finally got some real data I could try out and got the OK to bring in SYNCSORT for a trial (this was just before DFSORT came out IIRC). I also for completeness tried another sort product that just faded away (the name I mean). I did a benchmark and hands down SYNCSORT beat the pants off of their own sort. Just as I was about to suggest that syncsort be ordered DFSORT became available. So, as I wanted to compare apples to apples I got DFSORT in on a trial as well. Well I had issues with DFSORT. I think we were one of the first MP shops that tried it with DFSORT. I had to open a sev 1 PMR because of this. Politics being what they were I was pressured to come up with answers. To try and shorted this SYNCSORT was the cheapest(CPU usage) when it came to sort (story revised later). We got the application people to replace syncsort with their sort and it did help. 5 Years later at another shop using similar data (production) and SMF, DFSORT came out on top. I developed some really nasty data to test sort on and every version of sort that came out and DFSORT won by a small but in our case significant amout (10 percent was typical). The shop was pure COBOL and absolutely zero assembler so I did not have to try and put any bubble sort fires out. Ed -- 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: Region size
ROTFLMAO! They thing demand paging will be faster than CFW to SORTWK? Oh the pain... -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Mike Schwab Sent: Tuesday, March 22, 2011 1:41 PM To: IBM-MAIN@bama.ua.edu Subject: Re: [IBM-MAIN] Region size I have some users who requested 150GB of Paging packs so they could do an in core reorg of multiple M9 volume DB2 databases, because that was the fastest way. I told them that was too much and they needed to specify sort work statements. They resisted and the request is pending. On Tue, Mar 22, 2011 at 3:21 PM, Mark Pace pacemainl...@gmail.com wrote: I assume that since it used 1792MB it has to be from above the line. There is not a dump. The program ends nicely with an error message, not an IBM message, that it is out of memory. It's batch utility to massage SMF data and was not written inhouse. The SE is talking with them now. There suggestion was to process less data. :-D The LPAR is 4GB and I really don't know how much is to much. I don't have a default region size, that I know of. I allow the use of REGION=0M and don't have any exit to limit that size. -- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all? -- 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: Region size
I have an SE that has job running out of memory. The error message says that he ran out of storage at 1792MB. In my opinion, the odds are that this program has an error and it is running out of memory because of that error. Even if you were to increase the region size, it would still run out of memory. The owner of the program needs to determine what the problem is. And then if it truly is not an error and truly needs this much memory, the program needs to be re-written to use data spaces or above-2G storage. Peter Relson z/OS Core Technology Design -- 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: Region size
Although I am not familiar with the internal design of DFSORT and other major sort products, it is certainly possible to design a sort which uses the page data sets by explicitely paging blocks of data out and back in without using demand paging. We designed our own sort which has just that capability and it runs considerably faster than running with SORTWK data sets. This design does have drawbacks, such as the dedication of space for page data sets, which lasts for much longer than SORTWK data sets. However, with th price of DASD so low, it scarcely makes any difference any more. Tom Harper IMS Utilities Development Team Neon Enterprise Software Sugar Land, TX -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Ron Hawkins Sent: Wednesday, March 23, 2011 1:16 AM To: IBM-MAIN@bama.ua.edu Subject: Re: Region size ROTFLMAO! They thing demand paging will be faster than CFW to SORTWK? Oh the pain... -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Mike Schwab Sent: Tuesday, March 22, 2011 1:41 PM To: IBM-MAIN@bama.ua.edu Subject: Re: [IBM-MAIN] Region size I have some users who requested 150GB of Paging packs so they could do an in core reorg of multiple M9 volume DB2 databases, because that was the fastest way. I told them that was too much and they needed to specify sort work statements. They resisted and the request is pending. -- 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: Region size
Mark Pace wrote: I have an SE that has job running out of memory. The error message says that he ran out of storage at 1792MB. and There is not a dump. The program ends nicely with an error message, not an IBM message, that it is out of memory. It's batch utility to massage SMF data and was not written inhouse. The SE is talking with them now. There suggestion was to process less data. :-D Why not selecting shorter intervals of SMF data? Or process one LPAR at a stage? Or try massage the SMF data in two stages using work datasets as temporary storage? Peter Relson wrote: In my opinion, the odds are that this program has an error and it is running out of memory because of that error. Even if you were to increase the region size, it would still run out of memory. Of course. Since it ends 'nicely with an error message'. And then if it truly is not an error and truly needs this much memory, the program needs to be re-written to use data spaces or above-2G storage. Or use disk/tape as storage. To Mark: I am suspecting that the program may needs to be re-assembled to pickup the correct SMF record layout. Groete / Greetings Elardus Engelbrecht -- 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: Region size
Elardus Engelbrecht pisze: Mark Pace wrote: I have an SE that has job running out of memory. The error message says that he ran out of storage at 1792MB. and There is not a dump. The program ends nicely with an error message, not an IBM message, that it is out of memory. It's batch utility to massage SMF data and was not written inhouse. The SE is talking with them now. There suggestion was to process less data. :-D Why not selecting shorter intervals of SMF data? Or process one LPAR at a stage? IMHO it is definitely bad design. Regardless of input data size the program should not depend on the more data at input the more memory rule. Of course, if the program requirements does not depend on data size, then it's even more funny. Friday mode It's even more than new version Excel requires! /Friday mode -- 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 16.07.2010 r. kapita zakadowy BRE Banku SA (w caoci wpacony) wynosi 168.248.328 zotych. -- 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: Region size
Radoslaw Skorupka wrote: IMHO it is definitely bad design. Regardless of input data size the program should not depend on the more data at input the more memory rule. Of course, if the program requirements does not depend on data size, then it's even more funny. Agreed. 'memory hogs' are a bad design. If you can't rewrite the software, you can try to bypass the bad designs by re-selecting your input and hope for an useful output and ... ... 'program ends nicely without a nice message about memory'. :-[ Friday mode It's even more than new version Excel requires! /Friday mode S You will cause a memory leak! ( ugly bad pun intended! :-D ) Hmm: I wonder where does that faulty program of Mark got memory to moan and write about lack of memory? ;-D Groete / Greetings Elardus Engelbrecht -- 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: Region size
Tell the users to code REGION=150GB,ADDRSPC=REAL. They can run in a V=R region with 150GB of real storage, so they won't need to do any paging, thus eliminating the need for the 150GB of paging space. They will probably discover this option on their own and ask you for it if you don't suggest it first. Or they could write their own sort, get their own virtual storage (150GB above the bar), then pagefix all that storagte, and thus not have to worry about paging. I am looking forward to hearing the results of their bubble sort. g Or they could ask the vendor of the sort product they plan to use for some ideas on how to accomplish their goal. Perhaps some Googling for sort techniques and/or performance pitfalls might help them, too. Is there a SORT-MAIN forum? Bill Fairchild Rocket Software -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Mike Schwab Sent: Wednesday, March 23, 2011 12:09 AM To: IBM-MAIN@bama.ua.edu Subject: Re: Region size Yes I did. I even suggested they do a VTAPE sort because our VTAPE device is 4X faster than our ESS 800s and ESS F20s. On Tue, Mar 22, 2011 at 9:40 PM, Joel C. Ewing jcew...@acm.org wrote: I suppose you have at least tried to explain to those users that if they actually tell a sort program it can use 150 GiB more storage than the real storage on the machine that not only will they NOT get a fast sort, but they will get an incredibly slow and expensive one because of paging delays and paging overhead - and everything else running on the machine for the long time it will take this to run will also see response go to the dogs. They might not care about the latter, but some other users of the system with more clout might. A decent sort utility that is given a realistic amount of virtual storage that can be kept in its working set in real storage, and which knows that the bulk of its temporary storage is on slower external devices can optimize circles around the abuse of the paging system these users are requesting. If the users can't understand that argument, you can probably expect them to also write their own sort program and use a bubble sort - and be surprised when it takes several years to run with that volume of data! The task of sorting 150 GiB of data shouldn't be delegated to neophytes that don't understand that resources have limits and that there are good reasons why some techniques are deprecated. J. C. Ewing On 03/22/2011 03:41 PM, Mike Schwab wrote: I have some users who requested 150GB of Paging packs so they could do an in core reorg of multiple M9 volume DB2 databases, because that was the fastest way. I told them that was too much and they needed to specify sort work statements. They resisted and the request is pending. On Tue, Mar 22, 2011 at 3:21 PM, Mark Pacepacemainl...@gmail.com wrote: I assume that since it used 1792MB it has to be from above the line. There is not a dump. The program ends nicely with an error message, not an IBM message, that it is out of memory. It's batch utility to massage SMF data and was not written inhouse. The SE is talking with them now. There suggestion was to process less data. :-D The LPAR is 4GB and I really don't know how much is to much. I don't have a default region size, that I know of. I allow the use of REGION=0M and don't have any exit to limit that size. -- Joel C. Ewing, Fort Smith, AR jcew...@acm.org Bentonville, AR jcew...@acm.org -- 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 -- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all? -- 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: Region size
You will want to ensure that your system can support V=R. I know we have removed that capability here. Check IEASYS-- for the settings. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Bill Fairchild Sent: Wednesday, March 23, 2011 8:48 AM To: IBM-MAIN@bama.ua.edu Subject: Re: Region size Tell the users to code REGION=150GB,ADDRSPC=REAL. They can run in a V=R region with 150GB of real storage, so they won't need to do any paging, thus eliminating the need for the 150GB of paging space. They will probably discover this option on their own and ask you for it if you don't suggest it first. Or they could write their own sort, get their own virtual storage (150GB above the bar), then pagefix all that storagte, and thus not have to worry about paging. I am looking forward to hearing the results of their bubble sort. g Or they could ask the vendor of the sort product they plan to use for some ideas on how to accomplish their goal. Perhaps some Googling for sort techniques and/or performance pitfalls might help them, too. Is there a SORT-MAIN forum? Bill Fairchild Rocket Software -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Mike Schwab Sent: Wednesday, March 23, 2011 12:09 AM To: IBM-MAIN@bama.ua.edu Subject: Re: Region size Yes I did. I even suggested they do a VTAPE sort because our VTAPE device is 4X faster than our ESS 800s and ESS F20s. On Tue, Mar 22, 2011 at 9:40 PM, Joel C. Ewing jcew...@acm.org wrote: I suppose you have at least tried to explain to those users that if they actually tell a sort program it can use 150 GiB more storage than the real storage on the machine that not only will they NOT get a fast sort, but they will get an incredibly slow and expensive one because of paging delays and paging overhead - and everything else running on the machine for the long time it will take this to run will also see response go to the dogs. They might not care about the latter, but some other users of the system with more clout might. A decent sort utility that is given a realistic amount of virtual storage that can be kept in its working set in real storage, and which knows that the bulk of its temporary storage is on slower external devices can optimize circles around the abuse of the paging system these users are requesting. If the users can't understand that argument, you can probably expect them to also write their own sort program and use a bubble sort - and be surprised when it takes several years to run with that volume of data! The task of sorting 150 GiB of data shouldn't be delegated to neophytes that don't understand that resources have limits and that there are good reasons why some techniques are deprecated. J. C. Ewing On 03/22/2011 03:41 PM, Mike Schwab wrote: I have some users who requested 150GB of Paging packs so they could do an in core reorg of multiple M9 volume DB2 databases, because that was the fastest way. I told them that was too much and they needed to specify sort work statements. They resisted and the request is pending. On Tue, Mar 22, 2011 at 3:21 PM, Mark Pacepacemainl...@gmail.com wrote: I assume that since it used 1792MB it has to be from above the line. There is not a dump. The program ends nicely with an error message, not an IBM message, that it is out of memory. It's batch utility to massage SMF data and was not written inhouse. The SE is talking with them now. There suggestion was to process less data. :-D The LPAR is 4GB and I really don't know how much is to much. I don't have a default region size, that I know of. I allow the use of REGION=0M and don't have any exit to limit that size. -- Joel C. Ewing, Fort Smith, ARjcew...@acm.org Bentonville, AR jcew...@acm.org -- 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 -- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html The information contained in this e-mail may contain confidential and/or privileged information and is intended for the sole use of the intended recipient. If you
Re: Region size
Bill Fairchild wrote: Or they could ask the vendor of the sort product they plan to use for some ideas on how to accomplish their goal. Sort Package Vendors are lurking here. Just put the word 'Sort' somewhere in the subject and they will 'sort' you out. ;-D Perhaps some Googling for sort techniques and/or performance pitfalls might help them, too. There are lots of good hits for that out there on the internet. Is there a SORT-MAIN forum? Good question. But I can't do proper searches, because the word 'sort' is ambiguous in searches. 1. Sort - refers to listing/handling/managing of whatever. 2. Sort used as other meaning - 'We can sort this out for you for XYZ.' 3. I found thousands of 'dead' and useless links when googling or using yahoo. Even when searching for groups, I found useless links for groups unrelated to 'computer'. Are there good search arguments to use to discover such a (platform independent?) forum? Feel free to 'sort' me out... ;-D (I'm outta this thread for now because of drift from the original subject...) Groete / Greetings Elardus Engelbrecht -- 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: Region size
Tom, I agree the block paging technique is a good one, but I wasn't aware block paging was an asynchronous process. I can see where it would be faster when the size or the duration of the sort meant that the block page-in was a cache hit on the storage system. Where the block page-outs are filling cache and being destaged to disk I'm not as certain it will be faster than CFW IO to SORTWK. Page dataset writes will use more cache on HDS, and fill NVS on IBM much faster than CFW to SORTWK because there is only one copy of CFW, and the cache algorithms, on HDS at least, will try to defer destaging CFW. When the sort is large enough that the read back of block pages becomes a cache miss I think it will not match the IO performance of SORTWK IO when it reads back data. Note I'm just comparing IO performance, there may be other factors in your sort that make it better than DFSORT and SYNCSORT. Ron -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Tom Harper Sent: Wednesday, March 23, 2011 4:32 AM To: IBM-MAIN@bama.ua.edu Subject: Re: [IBM-MAIN] Region size Although I am not familiar with the internal design of DFSORT and other major sort products, it is certainly possible to design a sort which uses the page data sets by explicitely paging blocks of data out and back in without using demand paging. We designed our own sort which has just that capability and it runs considerably faster than running with SORTWK data sets. This design does have drawbacks, such as the dedication of space for page data sets, which lasts for much longer than SORTWK data sets. However, with th price of DASD so low, it scarcely makes any difference any more. Tom Harper IMS Utilities Development Team Neon Enterprise Software Sugar Land, TX -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Ron Hawkins Sent: Wednesday, March 23, 2011 1:16 AM To: IBM-MAIN@bama.ua.edu Subject: Re: Region size ROTFLMAO! They thing demand paging will be faster than CFW to SORTWK? Oh the pain... -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Mike Schwab Sent: Tuesday, March 22, 2011 1:41 PM To: IBM-MAIN@bama.ua.edu Subject: Re: [IBM-MAIN] Region size I have some users who requested 150GB of Paging packs so they could do an in core reorg of multiple M9 volume DB2 databases, because that was the fastest way. I told them that was too much and they needed to specify sort work statements. They resisted and the request is pending. -- 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: Region size
Ron, There are options in z/OS to PAGEOUT (PGSER OUT) virtual storage, which essentially is volunteering to have your pages placed on aux storage before stealing occurs. The pages are actually only written to aux if there is a shortage of real storage. This process is asynchronous. Similarly, when bringing the same blocks of virtual storage back in, the pages can be brought back in via PAGEIN (PGSER LOAD) in anticipation of their use to avoid a page fault. Tom Harper IMS Utilities Development Team Neon Enterprise Software Sugar Land, TX -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Ron Hawkins Sent: Wednesday, March 23, 2011 9:29 AM To: IBM-MAIN@bama.ua.edu Subject: Re: Region size Tom, I agree the block paging technique is a good one, but I wasn't aware block paging was an asynchronous process. ... Ron -- 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
Region size
I have an SE that has job running out of memory. The error message says that he ran out of storage at 1792MB. We have do not have an IEFUSI exit, and we are using the default IBM IEALIMIT. So with REGION=0M he should be getting everything possible. So as I understand it my only ability to give him more storage would be to shrink CSA/ECSA and SQA/ESQA. What I can't find is how to determine what are correct sizes for my environment. I don't want to just willy nilly reduce the sizes of these parameters and then have my system puke. What is the correct way to monitor and adjust these parameters? -- Mark D Pace Senior Systems Engineer Mainline Information Systems -- 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: Region size
Hi Mark, There are other places (e.g. JES exits) that can affect region sizes. I assume that you've checked obvious things: REGION=0M is specified on the JOB (i.e. to override any default) and no other REGION= parameter (e.g. on EXEC statements) is specified. The subpool associated with the failing request (should be displayed in the message and/or dump) is in the private area and RES=31 or RES=ANY I don't mean to be insultingly rudimentary; I often overlook things that stare me in the face. Cheers, Alan -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Mark Pace Sent: Tuesday, March 22, 2011 12:37 PM To: IBM-MAIN@bama.ua.edu Subject: Region size I have an SE that has job running out of memory. The error message says that he ran out of storage at 1792MB. We have do not have an IEFUSI exit, and we are using the default IBM IEALIMIT. So with REGION=0M he should be getting everything possible. So as I understand it my only ability to give him more storage would be to shrink CSA/ECSA and SQA/ESQA. What I can't find is how to determine what are correct sizes for my environment. I don't want to just willy nilly reduce the sizes of these parameters and then have my system puke. What is the correct way to monitor and adjust these parameters? -- Mark D Pace Senior Systems Engineer Mainline Information Systems -- 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: Region size
I'd tell the SE to go away and come back when s/he has some decent code. Not your problem. Dataspaces have been around for just a little while - then there is all that room above the (not so) new- fangled bar. Shane... On Wed, Mar 23rd, 2011 at 6:37 AM, Mark Pace pacemainl...@gmail.com wrote: I have an SE that has job running out of memory. The error message says that he ran out of storage at 1792MB. -- 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: Region size
I have an SE that has job running out of memory. The error message says that he ran out of storage at 1792MB. We have do not have an IEFUSI exit, and we are using the default IBM IEALIMIT. So with REGION=0M he should be getting everything possible. So as I understand it my only ability to give him more storage would be to shrink CSA/ECSA and SQA/ESQA. What I can't find is how to determine what are correct sizes for my environment. I don't want to just willy nilly reduce the sizes of these parameters and then have my system puke. What is the correct way to monitor and adjust these parameters? Mark, I am guessing that since they got 1792MB that this is above the line storage issue? Or is it below the line? Is this an S878 abend or some other type of issue? Do you have a dump? Does it show where the getmains are coming from? Sometimes I use a VSM trace to see what the application is getting and it what chunks. Is this a vendor package or inhouse written program? Is it DB2, IMS, CICS , MQ, etc... Is this cobol, assembler, C+, Java program? How much storage do you have on this LPAR and how big can a user request before it is too much? What is your default region size for all tasks? Lizette -- 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: Region size
Unfortunately the program was not written in house. He is talking with them about the problem, but in the mean time I was just trying to squeeze out as much Private space as possible. On Tue, Mar 22, 2011 at 4:07 PM, Shane Ginnane ibm-m...@tpg.com.au wrote: I'd tell the SE to go away and come back when s/he has some decent code. Not your problem. Dataspaces have been around for just a little while - then there is all that room above the (not so) new- fangled bar. Shane... On Wed, Mar 23rd, 2011 at 6:37 AM, Mark Pace pacemainl...@gmail.com wrote: I have an SE that has job running out of memory. The error message says that he ran out of storage at 1792MB. -- 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 -- Mark D Pace Senior Systems Engineer Mainline Information Systems -- 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: Region size
I assume that since it used 1792MB it has to be from above the line. There is not a dump. The program ends nicely with an error message, not an IBM message, that it is out of memory. It's batch utility to massage SMF data and was not written inhouse. The SE is talking with them now. There suggestion was to process less data. :-D The LPAR is 4GB and I really don't know how much is to much. I don't have a default region size, that I know of. I allow the use of REGION=0M and don't have any exit to limit that size. On Tue, Mar 22, 2011 at 4:14 PM, Lizette Koehler stars...@mindspring.comwrote: I have an SE that has job running out of memory. The error message says that he ran out of storage at 1792MB. We have do not have an IEFUSI exit, and we are using the default IBM IEALIMIT. So with REGION=0M he should be getting everything possible. So as I understand it my only ability to give him more storage would be to shrink CSA/ECSA and SQA/ESQA. What I can't find is how to determine what are correct sizes for my environment. I don't want to just willy nilly reduce the sizes of these parameters and then have my system puke. What is the correct way to monitor and adjust these parameters? Mark, I am guessing that since they got 1792MB that this is above the line storage issue? Or is it below the line? Is this an S878 abend or some other type of issue? Do you have a dump? Does it show where the getmains are coming from? Sometimes I use a VSM trace to see what the application is getting and it what chunks. Is this a vendor package or inhouse written program? Is it DB2, IMS, CICS , MQ, etc... Is this cobol, assembler, C+, Java program? How much storage do you have on this LPAR and how big can a user request before it is too much? What is your default region size for all tasks? Lizette -- 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 -- Mark D Pace Senior Systems Engineer Mainline Information Systems -- 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: Region size
...heard of this once: If MEMLIMIT is not specified in SMFPRMxx, the default value for this system default is 0M. ...value had been set as 1778M John Donnelly National Semiconductor Corporation 2900 Semiconductor Drive Santa Clara, CA 95051 408-721-5640 408-470-8364 Cell cjp...@nsc.com -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Mark Pace Sent: Tuesday, March 22, 2011 1:15 PM To: IBM-MAIN@bama.ua.edu Subject: Re: Region size Unfortunately the program was not written in house. He is talking with them about the problem, but in the mean time I was just trying to squeeze out as much Private space as possible. On Tue, Mar 22, 2011 at 4:07 PM, Shane Ginnane ibm-m...@tpg.com.au wrote: I'd tell the SE to go away and come back when s/he has some decent code. Not your problem. Dataspaces have been around for just a little while - then there is all that room above the (not so) new- fangled bar. Shane... On Wed, Mar 23rd, 2011 at 6:37 AM, Mark Pace pacemainl...@gmail.com wrote: I have an SE that has job running out of memory. The error message says that he ran out of storage at 1792MB. -- 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 -- Mark D Pace Senior Systems Engineer Mainline Information Systems -- 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: Region size
I have some users who requested 150GB of Paging packs so they could do an in core reorg of multiple M9 volume DB2 databases, because that was the fastest way. I told them that was too much and they needed to specify sort work statements. They resisted and the request is pending. On Tue, Mar 22, 2011 at 3:21 PM, Mark Pace pacemainl...@gmail.com wrote: I assume that since it used 1792MB it has to be from above the line. There is not a dump. The program ends nicely with an error message, not an IBM message, that it is out of memory. It's batch utility to massage SMF data and was not written inhouse. The SE is talking with them now. There suggestion was to process less data. :-D The LPAR is 4GB and I really don't know how much is to much. I don't have a default region size, that I know of. I allow the use of REGION=0M and don't have any exit to limit that size. -- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all? -- 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: Region size
I just verified that I have MEMLIMIT(0M) coded in SMFPRMxx On Tue, Mar 22, 2011 at 4:37 PM, Donnelly, John P john.p.donne...@nsc.comwrote: ...heard of this once: If MEMLIMIT is not specified in SMFPRMxx, the default value for this system default is 0M. ...value had been set as 1778M John Donnelly National Semiconductor Corporation 2900 Semiconductor Drive Santa Clara, CA 95051 408-721-5640 408-470-8364 Cell cjp...@nsc.com -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Mark Pace Sent: Tuesday, March 22, 2011 1:15 PM To: IBM-MAIN@bama.ua.edu Subject: Re: Region size Unfortunately the program was not written in house. He is talking with them about the problem, but in the mean time I was just trying to squeeze out as much Private space as possible. On Tue, Mar 22, 2011 at 4:07 PM, Shane Ginnane ibm-m...@tpg.com.au wrote: I'd tell the SE to go away and come back when s/he has some decent code. Not your problem. Dataspaces have been around for just a little while - then there is all that room above the (not so) new- fangled bar. Shane... On Wed, Mar 23rd, 2011 at 6:37 AM, Mark Pace pacemainl...@gmail.com wrote: I have an SE that has job running out of memory. The error message says that he ran out of storage at 1792MB. -- 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 -- Mark D Pace Senior Systems Engineer Mainline Information Systems -- 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 -- Mark D Pace Senior Systems Engineer Mainline Information Systems -- 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: Region size
I suppose you have at least tried to explain to those users that if they actually tell a sort program it can use 150 GiB more storage than the real storage on the machine that not only will they NOT get a fast sort, but they will get an incredibly slow and expensive one because of paging delays and paging overhead - and everything else running on the machine for the long time it will take this to run will also see response go to the dogs. They might not care about the latter, but some other users of the system with more clout might. A decent sort utility that is given a realistic amount of virtual storage that can be kept in its working set in real storage, and which knows that the bulk of its temporary storage is on slower external devices can optimize circles around the abuse of the paging system these users are requesting. If the users can't understand that argument, you can probably expect them to also write their own sort program and use a bubble sort - and be surprised when it takes several years to run with that volume of data! The task of sorting 150 GiB of data shouldn't be delegated to neophytes that don't understand that resources have limits and that there are good reasons why some techniques are deprecated. J. C. Ewing On 03/22/2011 03:41 PM, Mike Schwab wrote: I have some users who requested 150GB of Paging packs so they could do an in core reorg of multiple M9 volume DB2 databases, because that was the fastest way. I told them that was too much and they needed to specify sort work statements. They resisted and the request is pending. On Tue, Mar 22, 2011 at 3:21 PM, Mark Pacepacemainl...@gmail.com wrote: I assume that since it used 1792MB it has to be from above the line. There is not a dump. The program ends nicely with an error message, not an IBM message, that it is out of memory. It's batch utility to massage SMF data and was not written inhouse. The SE is talking with them now. There suggestion was to process less data. :-D The LPAR is 4GB and I really don't know how much is to much. I don't have a default region size, that I know of. I allow the use of REGION=0M and don't have any exit to limit that size. -- Joel C. Ewing, Fort Smith, ARjcew...@acm.org Bentonville, AR jcew...@acm.org -- 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: Region size
From: Mike Schwab mike.a.sch...@gmail.com To: IBM-MAIN@bama.ua.edu Sent: Tue, March 22, 2011 3:41:07 PM Subject: Re: Region size I have some users who requested 150GB of Paging packs so they could do an in core reorg of multiple M9 volume DB2 databases, because that was the fastest way. I told them that was too much and they needed to specify sort work statements. They resisted and the request is pending. Mike: 15 years ago I had the DB2 people demand another 10 paging packs. I ran a quick scan of SMF and it didn't indicate any need for 10 packs. I asked them to justify their needs. They ran to their boss and who inturned ran to their boss anyway you get the idea. They got their packs and it sat idle for over a year. I walked away muttering to myself. Ed -- 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: Region size
Yes I did. I even suggested they do a VTAPE sort because our VTAPE device is 4X faster than our ESS 800s and ESS F20s. On Tue, Mar 22, 2011 at 9:40 PM, Joel C. Ewing jcew...@acm.org wrote: I suppose you have at least tried to explain to those users that if they actually tell a sort program it can use 150 GiB more storage than the real storage on the machine that not only will they NOT get a fast sort, but they will get an incredibly slow and expensive one because of paging delays and paging overhead - and everything else running on the machine for the long time it will take this to run will also see response go to the dogs. They might not care about the latter, but some other users of the system with more clout might. A decent sort utility that is given a realistic amount of virtual storage that can be kept in its working set in real storage, and which knows that the bulk of its temporary storage is on slower external devices can optimize circles around the abuse of the paging system these users are requesting. If the users can't understand that argument, you can probably expect them to also write their own sort program and use a bubble sort - and be surprised when it takes several years to run with that volume of data! The task of sorting 150 GiB of data shouldn't be delegated to neophytes that don't understand that resources have limits and that there are good reasons why some techniques are deprecated. J. C. Ewing On 03/22/2011 03:41 PM, Mike Schwab wrote: I have some users who requested 150GB of Paging packs so they could do an in core reorg of multiple M9 volume DB2 databases, because that was the fastest way. I told them that was too much and they needed to specify sort work statements. They resisted and the request is pending. On Tue, Mar 22, 2011 at 3:21 PM, Mark Pacepacemainl...@gmail.com wrote: I assume that since it used 1792MB it has to be from above the line. There is not a dump. The program ends nicely with an error message, not an IBM message, that it is out of memory. It's batch utility to massage SMF data and was not written inhouse. The SE is talking with them now. There suggestion was to process less data. :-D The LPAR is 4GB and I really don't know how much is to much. I don't have a default region size, that I know of. I allow the use of REGION=0M and don't have any exit to limit that size. -- Joel C. Ewing, Fort Smith, AR jcew...@acm.org Bentonville, AR jcew...@acm.org -- 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 -- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all? -- 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
Paging - was: Re: Region size
Dataspaces have been around for just a little while - then there is all that room above the (not so) new-fangled bar. Don't get me started, Shane! Actually, my general paranoia about not allowing too much space above the bar because we cannot back it and the AUX storage will run out paid off big time recently: We are using a product called CFT (from Axway) in version 2.4. My colleague wanted to upgrade to version 2.6 in preparation for the z/OS migration. Unfortunately, CFT first 0C4'd because they could not deal with pcca/lcca above the line (which they had a fix for), and *then* they got the abenddc2 indicating a problem above the bar. - After quite a bit of bashing from me, Axway finally admitted that in release 2.6 they had gone from being a 2GB virtual STC to being a 2GB virtual STC PLUS 20 (twenty!) GB of storage above the bar DURING startup. All of it backed (they put a chain pointer on every page), none of it needed (after all, this is a test system with only 2GB real that never really transfers anything). None of this was documented anywhere, of course. They have accepted a 'requirement' that they cannot do that. But it will only be implemented in release 2.7. My management decided that we won't allow migration to a higher release until this is fixed. In essence, generally allowing memlimit to be unlimited is dangerous to any paging configuration! 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: Paging - was: Re: Region size
Another gem from Barbara! I love the way she starts her post's with don't get me started and then starts and finishes with such aplomb! On 23/03/2011 1:50 PM, Barbara Nitz wrote: Dataspaces have been around for just a little while - then there is all that room above the (not so) new-fangled bar. Don't get me started, Shane! Actually, my general paranoia about not allowing too much space above the bar because we cannot back it and the AUX storage will run out paid off big time recently: We are using a product called CFT (from Axway) in version 2.4. My colleague wanted to upgrade to version 2.6 in preparation for the z/OS migration. Unfortunately, CFT first 0C4'd because they could not deal with pcca/lcca above the line (which they had a fix for), and *then* they got the abenddc2 indicating a problem above the bar. - After quite a bit of bashing from me, Axway finally admitted that in release 2.6 they had gone from being a 2GB virtual STC to being a 2GB virtual STC PLUS 20 (twenty!) GB of storage above the bar DURING startup. All of it backed (they put a chain pointer on every page), none of it needed (after all, this is a test system with only 2GB real that never really transfers anything). None of this was documented anywhere, of course. They have accepted a 'requirement' that they cannot do that. But it will only be implemented in release 2.7. My management decided that we won't allow migration to a higher release until this is fixed. In essence, generally allowing memlimit to be unlimited is dangerous to any paging configuration! 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: Default REGION Size
In f393f47ecbe9fc4aa71b2a242c0b689512f3880...@hfdpmsgcms01.aeth.aetna.com, on 02/09/2011 at 09:46 AM, Veilleux, Jon L veilleu...@aetna.com said: The only problem with not limiting the region below is if you have a job that does a variable length getmain to take all available storage and then opens a lot of datasets you can get errors due to not enough below the line space for LSQA for the dataset control blocks. DEB's, yes, but IOB's et al don't go in LSQA. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- 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
Default REGION Size
We run a 4-system production sysplex using z/OS/JES2 1.11 augmented by Thruput Manager. As a result of an application area reporting one of their critical jobs abending S822 (issue since corrected), we found ourselves noticing a very old parm value: default REGION size for all classes via the JOBCLASS statement. It's still set to an 'ancient' value of 7M! Haven't assessed how many of our jobs simply accept the default, but I'm thinking of changing the default region size for all jobclasses to a more current value of 32M. In this day and age, not sure how many programmers have a handle on used virtual storage, and not sure it should still matter! Jobs simply shouldn't fail because of region size in this day and age IMHO. I don't know how other shops handle this, and would like to read your comments/thoughts/opinions on my suggested new default region size. Cheers, Stan Haynes z/OS Systems Analyst Canada Revenue Agency -- 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: Default REGION Size
We ignore it entirely by overriding via the IEFUSI exit. REGION is basically useless in this day and age, especially for batch. For UNIX work, it may be needed. And for some types of started tasks, such as DB2 (which we don't have), it can still be very necessary. -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * john.mck...@healthmarkets.com * www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Haynes, Stan Sent: Wednesday, February 09, 2011 8:04 AM To: IBM-MAIN@bama.ua.edu Subject: Default REGION Size We run a 4-system production sysplex using z/OS/JES2 1.11 augmented by Thruput Manager. As a result of an application area reporting one of their critical jobs abending S822 (issue since corrected), we found ourselves noticing a very old parm value: default REGION size for all classes via the JOBCLASS statement. It's still set to an 'ancient' value of 7M! Haven't assessed how many of our jobs simply accept the default, but I'm thinking of changing the default region size for all jobclasses to a more current value of 32M. In this day and age, not sure how many programmers have a handle on used virtual storage, and not sure it should still matter! Jobs simply shouldn't fail because of region size in this day and age IMHO. I don't know how other shops handle this, and would like to read your comments/thoughts/opinions on my suggested new default region size. Cheers, Stan Haynes z/OS Systems Analyst Canada Revenue Agency -- 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: Default REGION Size
On Wed, 9 Feb 2011 09:04:27 -0500, Haynes, Stan stan.hay...@cra-arc.gc.ca wrote: We run a 4-system production sysplex using z/OS/JES2 1.11 augmented by Thruput Manager. As a result of an application area reporting one of their critical jobs abending S822 (issue since corrected), we found ourselves noticing a very old parm value: default REGION size for all classes via the JOBCLASS statement. It's still set to an 'ancient' value of 7M! Haven't assessed how many of our jobs simply accept the default, but I'm thinking of changing the default region size for all jobclasses to a more current value of 32M. In this day and age, not sure how many programmers have a handle on used virtual storage, and not sure it should still matter! Jobs simply shouldn't fail because of region size in this day and age IMHO. I don't know how other shops handle this, and would like to read your comments/thoughts/opinions on my suggested new default region size. Assuming you don't have an IEFUSI exit in place, you wouldn't be gaining much by changing the default to 32M. The default above the line region is already 32M. You would probably gain 2M below the line, maybe 3M and that could help some batch jobs that aren't using REGION greater than 7M today and would abend if they needed more. See the MVS JCL Reference for more detail and you may want to read this article I wrote for TSO times about 7 years ago: Region Size: What You See is Not What You Get http://www.tsotimes.com/articles/archive/spring04/TSO-Times-Spring04.pdf The best thing to do would be to implement an IEFUSI and just ignore what is set in JES2 or (most) JCL for the defaults. 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: Default REGION Size
What about region=0m?? From what I remember it will take what is needed, the down side is if you have something run away(loop) you might be in trouble. Mace -- 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: Default REGION Size
I worked at a place that had a similar setup with 8M. It was set artificially low because there were a bunch of assembler programs in the shop that did a variable getmains to give them everything below the line. By setting it to 8M, it meant that they couldn't get everything below the line and thus the jobs would tend not to abend for exhausted storage below the line. Not a brilliant way to do things.. but it worked. Cheers, Rob -- 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: Default REGION Size
The only problem with not limiting the region below is if you have a job that does a variable length getmain to take all available storage and then opens a lot of datasets you can get errors due to not enough below the line space for LSQA for the dataset control blocks. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Larry Macioce Sent: Wednesday, February 09, 2011 9:27 AM To: IBM-MAIN@bama.ua.edu Subject: Re: Default REGION Size What about region=0m?? From what I remember it will take what is needed, the down side is if you have something run away(loop) you might be in trouble. Mace -- 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 This e-mail may contain confidential or privileged information. If you think you have received this e-mail in error, please advise the sender by reply e-mail and then delete this e-mail immediately. Thank you. Aetna -- 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: Default REGION Size
Yes. And no issue these days on probably 95% + of all systems with above the line either. 2G ain't what it used to be and with the size of today's systems and paging subsystems, even if more than a few of these ill-behaved programs all did the variable length getmains at the same time you probably wouldn't notice.Even my smallest system has 1.5G of real storage and my smallest sandbox LPAR has 1G. I still have my IEFUSI set with a default of 256M above, but anytime someone asks for more, they can have it. If they asks for 1G or more, they get everything above the line (which ends up being about 1700M-1800M on most of my systems). My last real update was in 2005 for MEMLIMIT (other than a slight change in 2007 for OA14391). The next time I do something with it, I'll probably just let all jobs/tasks get everything above the line and remove the 256M default. -- 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/ On Wed, 9 Feb 2011 09:46:49 -0500, Veilleux, Jon L veilleu...@aetna.com wrote: The only problem with not limiting the region below is if you have a job that does a variable length getmain to take all available storage and then opens a lot of datasets you can get errors due to not enough below the line space for LSQA for the dataset control blocks. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Larry Macioce Sent: Wednesday, February 09, 2011 9:27 AM To: IBM-MAIN@bama.ua.edu Subject: Re: Default REGION Size What about region=0m?? From what I remember it will take what is needed, the down side is if you have something run away(loop) you might be in trouble. Mace -- 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 This e-mail may contain confidential or privileged information. If you think you have received this e-mail in error, please advise the sender by reply e-mail and then delete this e-mail immediately. Thank you. Aetna -- 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: Default REGION Size
-Original Message- From: IBM Mainframe Discussion List On Behalf Of Haynes, Stan We run a 4-system production sysplex using z/OS/JES2 1.11 augmented by Thruput Manager. As a result of an application area reporting one of their critical jobs abending S822 (issue since corrected), we found ourselves noticing a very old parm value: default REGION size for all classes via the JOBCLASS statement. It's still set to an 'ancient' value of 7M! . . . When we went to z/OS 1.11, we finally raised our default region size from 1M all the way up to 4M! :-) TSO size was increased from 4096K to 131072K when Java entered the picture. -jc- -- 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: Default REGION Size
On Wed, Feb 9, 2011 at 8:46 AM, Veilleux, Jon L veilleu...@aetna.com wrote: The only problem with not limiting the region below is if you have a job that does a variable length getmain to take all available storage and then opens a lot of datasets you can get errors due to not enough below the line space for LSQA for the dataset control blocks. During a DR test our shop got S806s on DB2 jobs that don't specify a region and the program is too large to load. -- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all? -- 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: Default REGION Size
How was the S822 corrected? We get this occasionally and just drain and restart the failing initiator... Our JOBCLASS is set to 4M... John Donnelly National Semiconductor Corporation 2900 Semiconductor Drive Santa Clara, CA 95051 408-721-5640 408-470-8364 Cell cjp...@nsc.com -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Haynes, Stan Sent: Wednesday, February 09, 2011 6:04 AM To: IBM-MAIN@bama.ua.edu Subject: Default REGION Size We run a 4-system production sysplex using z/OS/JES2 1.11 augmented by Thruput Manager. As a result of an application area reporting one of their critical jobs abending S822 (issue since corrected), we found ourselves noticing a very old parm value: default REGION size for all classes via the JOBCLASS statement. It's still set to an 'ancient' value of 7M! Haven't assessed how many of our jobs simply accept the default, but I'm thinking of changing the default region size for all jobclasses to a more current value of 32M. In this day and age, not sure how many programmers have a handle on used virtual storage, and not sure it should still matter! Jobs simply shouldn't fail because of region size in this day and age IMHO. I don't know how other shops handle this, and would like to read your comments/thoughts/opinions on my suggested new default region size. Cheers, Stan Haynes z/OS Systems Analyst Canada Revenue Agency -- 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: Default REGION Size
On Wed, 9 Feb 2011 09:04:27 -0500, Haynes, Stan wrote: As a result of an application area reporting one of their critical jobs abending S822 (issue since corrected), we found ourselves noticing a very old parm value: default REGION size for all classes via the JOBCLASS statement. It's still set to an 'ancient' value of 7M! S822 is not because the region specified is too small. It is because the region specified was not available, possible due to fragmentation of LSQA. -- Tom Marchant -- 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: Default REGION Size
Is there any reason why you're not using the VSM CHECKREGIONLOSS parameter in your DIAGxx member Mark Jacobs On 02/09/11 11:26, Donnelly, John P wrote: How was the S822 corrected? We get this occasionally and just drain and restart the failing initiator... Our JOBCLASS is set to 4M... John Donnelly National Semiconductor Corporation 2900 Semiconductor Drive Santa Clara, CA 95051 408-721-5640 408-470-8364 Cell cjp...@nsc.com -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Haynes, Stan Sent: Wednesday, February 09, 2011 6:04 AM To: IBM-MAIN@bama.ua.edu Subject: Default REGION Size We run a 4-system production sysplex using z/OS/JES2 1.11 augmented by Thruput Manager. As a result of an application area reporting one of their critical jobs abending S822 (issue since corrected), we found ourselves noticing a very old parm value: default REGION size for all classes via the JOBCLASS statement. It's still set to an 'ancient' value of 7M! Haven't assessed how many of our jobs simply accept the default, but I'm thinking of changing the default region size for all jobclasses to a more current value of 32M. In this day and age, not sure how many programmers have a handle on used virtual storage, and not sure it should still matter! Jobs simply shouldn't fail because of region size in this day and age IMHO. I don't know how other shops handle this, and would like to read your comments/thoughts/opinions on my suggested new default region size. Cheers, Stan Haynes z/OS Systems Analyst Canada Revenue Agency -- Mark Jacobs Time Customer Service Tampa, FL Surrounding yourself with dwarfs does not make you a giant -- 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: Default REGION Size
Do you have CHECKREGIONLOSS set in your DIAG member? It will automatically bounce your initiators when they get fragmented. VSM CHECKREGIONLOSS(500K,5M) -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Donnelly, John P Sent: Wednesday, February 09, 2011 11:26 AM To: IBM-MAIN@bama.ua.edu Subject: Re: Default REGION Size How was the S822 corrected? We get this occasionally and just drain and restart the failing initiator... Our JOBCLASS is set to 4M... John Donnelly National Semiconductor Corporation 2900 Semiconductor Drive Santa Clara, CA 95051 408-721-5640 408-470-8364 Cell cjp...@nsc.com -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Haynes, Stan Sent: Wednesday, February 09, 2011 6:04 AM To: IBM-MAIN@bama.ua.edu Subject: Default REGION Size We run a 4-system production sysplex using z/OS/JES2 1.11 augmented by Thruput Manager. As a result of an application area reporting one of their critical jobs abending S822 (issue since corrected), we found ourselves noticing a very old parm value: default REGION size for all classes via the JOBCLASS statement. It's still set to an 'ancient' value of 7M! Haven't assessed how many of our jobs simply accept the default, but I'm thinking of changing the default region size for all jobclasses to a more current value of 32M. In this day and age, not sure how many programmers have a handle on used virtual storage, and not sure it should still matter! Jobs simply shouldn't fail because of region size in this day and age IMHO. I don't know how other shops handle this, and would like to read your comments/thoughts/opinions on my suggested new default region size. Cheers, Stan Haynes z/OS Systems Analyst Canada Revenue Agency -- 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 This e-mail may contain confidential or privileged information. If you think you have received this e-mail in error, please advise the sender by reply e-mail and then delete this e-mail immediately. Thank you. Aetna -- 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: Default REGION Size
As Tom Marchant pointed out, it's likely LSQA fragmentation. And the S822 was misleading: the step requested 8M but turns out only needed 2M. So getting everything avail in 16M private on the job rerun worked. We (the small z/OS sysprog group) missed CHECKREGIONLOSS. Plain and simple. That will be addressed. Restarting an initiator is easy enough to do, but while fragmentation can happen (and you take a hit to find out), you want to avoid the easy S822's like the one we had. The issue with how much *low* private to allow is ensuring RTM can successfully GETMAIN, so I'm wondering: if we change the default to 128M, or 192M, etc, do we need to subtract some vstor for the low private ? Stan mailto:stan.hay...@cra-arc.gc.ca (613) 941-8091 -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Mark Jacobs Sent: February 9, 2011 11:41 AM To: IBM-MAIN@bama.ua.edu Subject: Re: Default REGION Size Is there any reason why you're not using the VSM CHECKREGIONLOSS parameter in your DIAGxx member Mark Jacobs On 02/09/11 11:26, Donnelly, John P wrote: How was the S822 corrected? We get this occasionally and just drain and restart the failing initiator... Our JOBCLASS is set to 4M... John Donnelly National Semiconductor Corporation 2900 Semiconductor Drive Santa Clara, CA 95051 408-721-5640 408-470-8364 Cell cjp...@nsc.com -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Haynes, Stan Sent: Wednesday, February 09, 2011 6:04 AM To: IBM-MAIN@bama.ua.edu Subject: Default REGION Size We run a 4-system production sysplex using z/OS/JES2 1.11 augmented by Thruput Manager. As a result of an application area reporting one of their critical jobs abending S822 (issue since corrected), we found ourselves noticing a very old parm value: default REGION size for all classes via the JOBCLASS statement. It's still set to an 'ancient' value of 7M! Haven't assessed how many of our jobs simply accept the default, but I'm thinking of changing the default region size for all jobclasses to a more current value of 32M. In this day and age, not sure how many programmers have a handle on used virtual storage, and not sure it should still matter! Jobs simply shouldn't fail because of region size in this day and age IMHO. I don't know how other shops handle this, and would like to read your comments/thoughts/opinions on my suggested new default region size. Cheers, Stan Haynes z/OS Systems Analyst Canada Revenue Agency -- Mark Jacobs Time Customer Service Tampa, FL Surrounding yourself with dwarfs does not make you a giant -- 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: Default REGION Size
snip-- We run a 4-system production sysplex using z/OS/JES2 1.11 augmented by Thruput Manager. As a result of an application area reporting one of their critical jobs abending S822 (issue since corrected), we found ourselves noticing a very old parm value: default REGION size for all classes via the JOBCLASS statement. It's still set to an 'ancient' value of 7M! Haven't assessed how many of our jobs simply accept the default, but I'm thinking of changing the default region size for all jobclasses to a more current value of 32M. In this day and age, not sure how many programmers have a handle on used virtual storage, and not sure it should still matter! Jobs simply shouldn't fail because of region size in this day and age IMHO. I don't know how other shops handle this, and would like to read your comments/thoughts/opinions on my suggested new default region size. unsnip--- I've always used a custom-built IEFACTRT exit. Free upon request via private E-Mail. Rick -- 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: Default REGION Size
On Wed, 9 Feb 2011 12:28:36 -0500, Haynes, Stan stan.hay...@cra-arc.gc.ca wrote: The issue with how much *low* private to allow is ensuring RTM can successfully GETMAIN, so I'm wondering: if we change the default to 128M, or 192M, etc, do we need to subtract some vstor for the low private ? That is why you need an IEFUSI (or IEALIMIT) exit. I really wish MVS would externalize LSQA reservation, above and below the line region size defaults etc.. in a parmlib member. But of course an exit is much more flexible since you may need more than a one size fits all specification. (not that jobnames etc. couldn't be added to some parmlib member to override the defaults) 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: Default REGION Size
It would be great if IEFUSI limits could be externalized into PARMLIB. It is a pain to have to recode an assembler exit whenever we need to change how we handle these limits. Not to mention that there are not a lot of us left who know how to code in assembler. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Mark Zelden Sent: Wednesday, February 09, 2011 12:57 PM To: IBM-MAIN@bama.ua.edu Subject: Re: Default REGION Size On Wed, 9 Feb 2011 12:28:36 -0500, Haynes, Stan stan.hay...@cra-arc.gc.ca wrote: The issue with how much *low* private to allow is ensuring RTM can successfully GETMAIN, so I'm wondering: if we change the default to 128M, or 192M, etc, do we need to subtract some vstor for the low private ? That is why you need an IEFUSI (or IEALIMIT) exit. I really wish MVS would externalize LSQA reservation, above and below the line region size defaults etc.. in a parmlib member. But of course an exit is much more flexible since you may need more than a one size fits all specification. (not that jobnames etc. couldn't be added to some parmlib member to override the defaults) 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 This e-mail may contain confidential or privileged information. If you think you have received this e-mail in error, please advise the sender by reply e-mail and then delete this e-mail immediately. Thank you. Aetna -- 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: Default REGION Size
I think there is a product to do this kind of stuff. OESM or something along those lines. I did a quick web search and obviously I don't have the right name. Rob On Wed, Feb 9, 2011 at 1:02 PM, Veilleux, Jon L veilleu...@aetna.comwrote: It would be great if IEFUSI limits could be externalized into PARMLIB. It is a pain to have to recode an assembler exit whenever we need to change how we handle these limits. Not to mention that there are not a lot of us left who know how to code in assembler. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Mark Zelden Sent: Wednesday, February 09, 2011 12:57 PM To: IBM-MAIN@bama.ua.edu Subject: Re: Default REGION Size On Wed, 9 Feb 2011 12:28:36 -0500, Haynes, Stan stan.hay...@cra-arc.gc.ca wrote: The issue with how much *low* private to allow is ensuring RTM can successfully GETMAIN, so I'm wondering: if we change the default to 128M, or 192M, etc, do we need to subtract some vstor for the low private ? That is why you need an IEFUSI (or IEALIMIT) exit. I really wish MVS would externalize LSQA reservation, above and below the line region size defaults etc.. in a parmlib member. But of course an exit is much more flexible since you may need more than a one size fits all specification. (not that jobnames etc. couldn't be added to some parmlib member to override the defaults) 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 This e-mail may contain confidential or privileged information. If you think you have received this e-mail in error, please advise the sender by reply e-mail and then delete this e-mail immediately. Thank you. Aetna -- 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 -- Rob Schramm Senior Systems Engineer w: 513.305.6224 -- 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: Default REGION Size
OSEM - from Trident Services Jerry Whitteridge Design Engineer Safeway Inc. 925 951 4184 If you feel in control you just aren't going fast enough. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Rob Schramm Sent: Wednesday, February 09, 2011 10:08 AM To: IBM-MAIN@bama.ua.edu Subject: Re: Default REGION Size I think there is a product to do this kind of stuff. OESM or something along those lines. I did a quick web search and obviously I don't have the right name. Rob On Wed, Feb 9, 2011 at 1:02 PM, Veilleux, Jon L veilleu...@aetna.comwrote: It would be great if IEFUSI limits could be externalized into PARMLIB. It is a pain to have to recode an assembler exit whenever we need to change how we handle these limits. Not to mention that there are not a lot of us left who know how to code in assembler. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Mark Zelden Sent: Wednesday, February 09, 2011 12:57 PM To: IBM-MAIN@bama.ua.edu Subject: Re: Default REGION Size On Wed, 9 Feb 2011 12:28:36 -0500, Haynes, Stan Stan.Haynes@CRA- ARC.GC.CA wrote: The issue with how much *low* private to allow is ensuring RTM can successfully GETMAIN, so I'm wondering: if we change the default to 128M, or 192M, etc, do we need to subtract some vstor for the low private ? That is why you need an IEFUSI (or IEALIMIT) exit. I really wish MVS would externalize LSQA reservation, above and below the line region size defaults etc.. in a parmlib member. But of course an exit is much more flexible since you may need more than a one size fits all specification. (not that jobnames etc. couldn't be added to some parmlib member to override the defaults) 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 This e-mail may contain confidential or privileged information. If you think you have received this e-mail in error, please advise the sender by reply e-mail and then delete this e-mail immediately. Thank you. Aetna -- 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 -- Rob Schramm Senior Systems Engineer w: 513.305.6224 -- 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 Email Firewall made the following annotations. -- Warning: All e-mail sent to this address will be received by the corporate e-mail system, and is subject to archival and review by someone other than the recipient. This e-mail may contain proprietary information and is intended only for the use of the intended recipient(s). If the reader of this message is not the intended recipient(s), you are notified that you have received this message in error and that any review, dissemination, distribution or copying of this message is strictly prohibited. If you have received this message in error, please notify the sender immediately. == -- 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: Region Size - Step or Jobcard
re: http://www.garlic.com/~lynn/2010m.html#16 Region Size - Step or Jobcard i.e. MVS was still mostly the same address space ... or every MVS virtual address space was mostly the same (some installations, 13mbytes threatening to become 14mbytes, of every 16mbyte virtual address space) ... in large part because of the engrained, pervasive pointer-passing API paradigm. -- virtualization experience starting Jan1968, online at home since Mar1970 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Region Size - Step or Jobcard
Someone asked me the question, and since we are having a good discussion, I thought I would throw this out to the collective wisdom here. If there is a job with 200+ steps. Is it better to have region coded at the JOBCARD level or the STEP Level? I have heard various thoughts on this over the years and I am hoping for some better clarification other than I think I remember that Lizette -- 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: Region Size - Step or Jobcard
In days of yore, long, long ago, and far, far, away, it made sense to code at the step level. OS/MVT used a contiguous storage algorithm and reserved that storage for the life of a job step.. If STEPB required more storage that STEPA, the possibility existed for significant execution delays until a contiguous block of real storage large enough for STEPB to execute became available. Great amounts of time and effort were spent determining actual real storage requirements and maintaining cascading region parameters to ensure that there was always enough contiguous real storage for the next job step. Potentially large amounts of real storage were wasted on small (real storage) steps executing before the large (real storage) step. All of the above went the way of the dodo when OS/MVS (specifically, virtual storage) became available. IMO, it no longer makes any sense to even worry about it. I do not believe any benefit (or not) would even be measureable. HTH, snip If there is a job with 200+ steps. Is it better to have region coded at the JOBCARD level or the STEP Level? /snip -- 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: Region Size - Step or Jobcard
IMHO, whatever is, leave it. There would not be enough potential benefit to justify the risks and cost. My $0.02 -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Lizette Koehler Sent: Wednesday, August 04, 2010 1:07 PM To: IBM-MAIN@bama.ua.edu Subject: Region Size - Step or Jobcard Someone asked me the question, and since we are having a good discussion, I thought I would throw this out to the collective wisdom here. If there is a job with 200+ steps. Is it better to have region coded at the JOBCARD level or the STEP Level? I have heard various thoughts on this over the years and I am hoping for some better clarification other than I think I remember that Lizette NOTICE: This electronic mail message and any files transmitted with it are intended exclusively for the individual or entity to which it is addressed. The message, together with any attachment, may contain confidential and/or privileged information. Any unauthorized review, use, printing, saving, copying, disclosure or distribution is strictly prohibited. If you have received this message in error, please immediately advise the sender by reply email and delete all copies. -- 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: Region Size - Step or Jobcard
W dniu 2010-08-04 20:07, Lizette Koehler pisze: Someone asked me the question, and since we are having a good discussion, I thought I would throw this out to the collective wisdom here. If there is a job with 200+ steps. Is it better to have region coded at the JOBCARD level or the STEP Level? I have heard various thoughts on this over the years and I am hoping for some better clarification other than I think I remember that 1. I think, it really doesn't matter *in practice*. 2. Without knowledge of the job steps it's impossible to answer. Example: 199 steps with IEFBR14 and 1 with MYPROG. Or the opposite... -- Radoslaw Skorupka Lodz, Poland -- BRE Bank SA ul. Senatorska 18 00-950 Warszawa www.brebank.pl Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, nr rejestru przedsiębiorców KRS 025237 NIP: 526-021-50-88 Według stanu na dzień 01.01.2009 r. kapitał zakładowy BRE Banku SA (w całości wpłacony) wynosi 118.763.528 złotych. W związku z realizacją warunkowego podwyższenia kapitału zakładowego, na podstawie uchwały XXI WZ z dnia 16 marca 2008r., oraz uchwały XVI NWZ z dnia 27 października 2008r., może ulec podwyższeniu do kwoty 123.763.528 zł. Akcje w podwyższonym kapitale zakładowym BRE Banku SA będą w całości opłacone. -- 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: Region Size - Step or Jobcard
On Wed, 4 Aug 2010 13:24:02 -0500, Staller, Allan wrote: In days of yore, long, long ago, and far, far, away, it made sense to code at the step level. OS/MVT used a contiguous storage algorithm More precisely, MVT had a single address space and reserved that storage for the life of a job step.. If STEPB required more storage that STEPA, the possibility existed for significant execution delays until a contiguous block of real storage large enough for STEPB to execute became available. At the shop where I started in 1970, we did just the opposite. All regions were coded on the JOB card and there was a standard for what the region would be. IIRC, Class A always used 110K. This was to avoid storage fragmentation. Today it is much less important. I usually code region on the JOB statement, but that's a personal preference. I don't believe in changing existing JCL without a good reason. -- Tom Marchant -- 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: Region Size - Step or Jobcard
On Wed, 4 Aug 2010 14:07:20 -0400, Lizette Koehler stars...@mindspring.com wrote: Someone asked me the question, and since we are having a good discussion, I thought I would throw this out to the collective wisdom here. If there is a job with 200+ steps. Is it better to have region coded at the JOBCARD level or the STEP Level? I have heard various thoughts on this over the years and I am hoping for some better clarification other than I think I remember that Lizette The less JCL coding, the better. And if you have system-exits that force such limits, coding a value may have no impact. Or if you have such small default-value defined for jobs, that could also have in impact -- for example, the minimum REGION required for a particular SAS conversion required a JCL change, however instead the JCL parameter was removed altogether. However, do consider that 'assigned JOB-level REGION, sets the max limit for any subordinate job-step, unless an exit gets involved. Scott Barry SBBWorks, Inc. -- 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: Region Size - Step or Jobcard
For new JCL I always recommend just putting an ample region size on the job card and be done with it. But I would certainly not change running JCL for no reason. I always say if it ain't broke don't break it. C. Todd Burrell PMP, MCSE 2003:Security Security+, Network+ Lead z/OS Systems Programmer ITSO (404) 723-2017 (Cell) -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Lizette Koehler Sent: Wednesday, August 04, 2010 2:07 PM To: IBM-MAIN@bama.ua.edu Subject: Region Size - Step or Jobcard Someone asked me the question, and since we are having a good discussion, I thought I would throw this out to the collective wisdom here. If there is a job with 200+ steps. Is it better to have region coded at the JOBCARD level or the STEP Level? I have heard various thoughts on this over the years and I am hoping for some better clarification other than I think I remember that Lizette -- 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: Region Size - Step or Jobcard
If you have a problem with the region size, add a REGION parameter to the jobcard that is equal to or larger than any step, and overrides all the steps. No need to remove the REGION from the steps or procs, and any changes to the values could result in typo abends. On Wed, Aug 4, 2010 at 2:43 PM, Burrell, C. Todd (CDC/OCOO/ITSO) (CTR) z...@cdc.gov wrote: For new JCL I always recommend just putting an ample region size on the job card and be done with it. But I would certainly not change running JCL for no reason. I always say if it ain't broke don't break it. C. Todd Burrell PMP, MCSE 2003:Security Security+, Network+ Lead z/OS Systems Programmer ITSO (404) 723-2017 (Cell) -- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all? -- 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: Region Size - Step or Jobcard
m42tom-ibmm...@yahoo.com (Tom Marchant) writes: More precisely, MVT had a single address space aka VS2/SVS was minimally modified MVT in a single (16mbyte) virtual address space; biggest change was borrowing ccwtrans from cp67 for EXCP ... to take the application-passed channel program and make a copy of it ... substituting real addresses for virtual addresses. there was a specially modified MVT os/360 relase 13 done at boeing huntsville. MVT storage/memory management became heavily fragmented with long running jobs. boeing huntsville had a pair of 360/67s for long running cad/cam jobs with 2250 vector graphics under MVT OS/360 release 13. MVT release 13 was modified to use the 360/67 virtual memory hardware to reoganize storage/memory locations (compensating for enormous storage fragmentation). there was no paging going on ... just address translation. the os/360 single address space contributed heavily to pervasive pointer-passing paradigm (also efficiency in limited storage/memory environments). this caused all sorts of problems attempting to deploy MVS with multiple virtual address spaces. MVS kernel image was made half of each 16mbyte application virtual address space (to simplify pervasive use of pointer-passing APIs). The problem manifested itself when all the subsystems were also moved into their own separate address space ... now the pointer-passing API between applications and subsystems started to break down. The solution was the common segment ... a part of every virtual address space that could have dedicated areas for moving parameters into so as to not breack the pointer passing API paradigm. The problem was that the demand for common segment area grew as the size of systems and number of subsystems grew. Some large MVS shops were even facing the possibility of moving from 5mbyte common segment to 6mbyte common segment ... reducing maximum application area to 2mbytes. Burlington ... internal chip foundary and big internal MVS shop had an enormous problem ... with major fortran applications that were constantly threatening to exceed 7mbytes and lots of carefully crafted MVS systems that maintained the common segment at 1mbyte. Move off MVS to CMS would have eliminated a whole lot of effort that was constantly going into keeping their applications working in the MVS environment ... but that would have been an enormous blow to MVS prestige and image. -- virtualization experience starting Jan1968, online at home since Mar1970 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Region Size - Step or Jobcard
For new JCL I always recommend just putting an ample region size on the job card and be done with it. But I would certainly not change running JCL for no reason. I always say if it ain't broke don't break it. I say implement an IEFUSI exit that isn't from the dark ages and not worry about (or ignore) what users code for (at least most) JCL. I shouldn't talk too much because I still haven't changed the default from 256M above. The below default is 7M and I'm sure 8M or even 9M wouldn't be a problem and would leave plenty of room for LSQA below the line (which I reserve 512K anyway). None of the LPARs I work with have less than 10M private below the line. Typically STCs code REGION=0M which I only allow (don't ignore) for STCs and that gives them everything they need anyway. BATCH that codes REGION=0M is penalized by getting the default, but I haven't found a batch job that ever needed more than 256M. If it did need more, I allow whatever is specified except for 0M (throw back to the old days - even the smallest LPAR I support has 1.5G real and a robust paging subsystem). 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: Region Size - Step or Jobcard
If there is a job with 200+ steps. Is it better to have region coded at the JOBCARD level or the STEP Level? Actually, while I still recommend using region at the job card level, in your particular case it will narrow the step that caused the fragmentation. Assuming you use checkregionloss and did NOT have a fragmented init when the job started. (Also assuming that the 822 is reproducible for *this* job.) I also strongly urge you to investigate the 822 *before* giving the job a region of 0M and removing individual region sizes. You might end up with abend878 -10 or -C or abend80A in steps after the IEFBR14 step. Unequivocally setting region=0M is covering up a problem that might hit you very hard when you can least afford it. 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: TSO region size
--- On Tue, 6/29/10, Anne Lynn Wheeler l...@garlic.com wrote: From: Anne Lynn Wheeler l...@garlic.com Subject: Re: TSO region size To: IBM-MAIN@bama.ua.edu Date: Tuesday, June 29, 2010, 2:07 PM gerh...@valley.net (Gerhard Postpischil) writes: That doesn't sound right. Each TSO session runs in its own region, and you need an additional TCAM or VTAM region to handle terminal I/O. A machine with 4MB was considered large. So if you had three sessions of that size, your machine probably wasn't doing much else. In our case we opted to run Wylbur, with dozens of users, which gave as much higher productivity. --SMIP-- They may not have been running MVS. We had to shut down TSO on the weekends so production could get the memory.This was a 30+ years ago and I was 'asked to explain the issue to the data center manager. He was not lets say smart (but not dumb either). I asked if I could erase some of his white board and I was drawing pictures (I understood) and at the end I summed it up as to that is why under MVS you do not have these issues under our SVS system you did. The woman in the room was smart but she said she somewhat understood and the manager said it didn't make sense and he was lost at virtual.I went through it again and explained how DAT worked carefully this time. I got done and he said he understood it. I left feeling I had accomplished something, ahh but I hadn't. The next week I get a call to go to floor 1720(if memory serves me) with no indication who was there and what (if anything was needed). I showed up and both people were there. The DC manager explained to me that they still did not get virtual and would I explain it one more time. So I took them from ground zero to Virtual and was asking if they understood or did I have to explain again. This time both got it and was extremely pleased that I was able to get them up to speed. I said no problem and walked out of the conference room think wow I am glad I am done with that. The next week I get a call from my VP asking if I had some time this Thursday(I think) and said well how long will I need as I have something I have to do Thursday afternoon. He assured me 2-3 hours would be the max.Anyway I walk into the room where this meeting was to be held and every single programming manager was there along with some staff. I was asked to give the class to the rest of the organization. Oh great a group that will give me no end of grief. So I got up and used the white board and gave the same spiel to the management of programming. I went through the second spiel I gave the DC manager. I got only one question and that not even being close to a real question. I said wait till we are done and then I will answer the question.After I got done I asked if there were any questions and I got one or two that I had talked about but didn't understand how relocation occurred so I answered the question using the same terminology I had used the first time but this time I stepped them through exactly what was going on and all of a sudden both faces lit up and they said my explanation answered their question to a T. I asked once more if there were any questions and everybody seemed to understand. I am guessing it went really well as all the managers thanked my VP and he relayed it on to me. I got a bunch of free dinners (on the expense account but it was the thought that was important). Ed -- 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: TSO region size
Ted MacNEIL pisze: 2G = 2,000,000,000 2Gi = 2,147,483,648 Where is 2Gi a documented standard, other than IBM-Main? Yes. This is official (documented standard) way of naming binary prefixes. However it's rarely used. For example - IBM mainframe documentation widely use the old way, that mean no MiB, GiB, or KiB can be observed. This is as pedantic as the 'true meaning' of USS. No. Meaning of USS is idee fixe of one or two guys on this forum. It is NOT a standard. USS is widely used as Unix System Services even by IBM. Sometimes mentioned IBM official acronym is NOT documented for public - there are no such list of official IBM acronyms available. Last, but not least: acronym is a matter of English language, not an asset of any company. And it's natural feature of acronym to be overloaded (to have more than 1 meaning). To me, 2048M is 2G, and when it's on disk, 2000M is 2G. And for most IT-specialists too, including IBM mainframe. That was the distinction taught in University in the 1970's. This isn't good argument. Times are a changing. You probably were not taught about EURO currency or 64-bit JAVA. Regards -- Radoslaw Skorupka Lodz, Poland -- BRE Bank SA ul. Senatorska 18 00-950 Warszawa www.brebank.pl Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, nr rejestru przedsiębiorców KRS 025237 NIP: 526-021-50-88 Według stanu na dzień 01.01.2009 r. kapitał zakładowy BRE Banku SA (w całości wpłacony) wynosi 118.763.528 złotych. W związku z realizacją warunkowego podwyższenia kapitału zakładowego, na podstawie uchwały XXI WZ z dnia 16 marca 2008r., oraz uchwały XVI NWZ z dnia 27 października 2008r., może ulec podwyższeniu do kwoty 123.763.528 zł. Akcje w podwyższonym kapitale zakładowym BRE Banku SA będą w całości opłacone. -- 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: TSO region size
On 06/30/2010 03:42 AM, R.S. wrote: Ted MacNEIL pisze: 2G = 2,000,000,000 2Gi = 2,147,483,648 Where is 2Gi a documented standard, other than IBM-Main? Yes. This is official (documented standard) way of naming binary prefixes. However it's rarely used. For example - IBM mainframe documentation widely use the old way, that mean no MiB, GiB, or KiB can be observed. This is as pedantic as the 'true meaning' of USS. No. Meaning of USS is idee fixe of one or two guys on this forum. It is NOT a standard. USS is widely used as Unix System Services even by IBM. Sometimes mentioned IBM official acronym is NOT documented for public - there are no such list of official IBM acronyms available. Last, but not least: acronym is a matter of English language, not an asset of any company. And it's natural feature of acronym to be overloaded (to have more than 1 meaning). To me, 2048M is 2G, and when it's on disk, 2000M is 2G. And for most IT-specialists too, including IBM mainframe. That was the distinction taught in University in the 1970's. This isn't good argument. Times are a changing. You probably were not taught about EURO currency or 64-bit JAVA. Regards In the 1970's this distinction was actually explicitly documented in IBM Manuals for the S/360 family, that K M were 2**10, 2**20 for memory but 10**3 and 10**6 for other contexts (DASD). Those in the profession understood it was the binary addressing of memory and non-binary constraints on DASD that made these distinctions rational. On architectures with decimal memory addressing, K was still 10**3, and on architectures with binary addressing but where machine words and instructions were written in octal, K = 2**9 was even used. Then came the great influx of newbies with the PC revolution in the late 1980's and 1990's and people unfamiliar with hardware architecture and the motivations behind the distinction began randomly using the binary prefixes in inappropriate contexts. The only way to eliminate the resulting mishmash and ambiguity was to come up with a new standard. Hopefully it won't take another 30 years for people to learn how to use it! -- Joel C. Ewing, Fort Smith, ARjremoveccapsew...@acm.org -- 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: TSO region size
Joel C. Ewing pisze: Then came the great influx of newbies with the PC revolution in the late 1980's and 1990's and people unfamiliar with hardware architecture and the motivations behind the distinction began randomly using the binary prefixes in inappropriate contexts. Even PC newbies did understand binary architecture. However they did use MS-DOS which used binary prefixes for disk. See FDISK. It was reasonable, because most DOS constraints for disk data were binary. So for PC people kB meant 1024 on both disk and RAM. BTW: 1.44MB floppy disk is curiosum - it is 1000*1024. -- Radoslaw Skorupka Lodz, Poland -- BRE Bank SA ul. Senatorska 18 00-950 Warszawa www.brebank.pl Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, nr rejestru przedsiębiorców KRS 025237 NIP: 526-021-50-88 Według stanu na dzień 01.01.2009 r. kapitał zakładowy BRE Banku SA (w całości wpłacony) wynosi 118.763.528 złotych. W związku z realizacją warunkowego podwyższenia kapitału zakładowego, na podstawie uchwały XXI WZ z dnia 16 marca 2008r., oraz uchwały XVI NWZ z dnia 27 października 2008r., może ulec podwyższeniu do kwoty 123.763.528 zł. Akcje w podwyższonym kapitale zakładowym BRE Banku SA będą w całości opłacone. -- 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
TSO region size
Hello List, We are standardising our default TSO region sizes on 64MB since we start seeing more and more problems with programs abending, because people still have 4MB region size as a default. 64MB seemed like a reasonable value to solve some of the issues and not introduce any new. Testing the changes I noticed when I log on to TSO the help panel says that the maximum possible region size is 2096128. This is 1 MB less than 2 GB, which would be 2097152. Can somebody tell me why the max is not exactly 2GB? Regards, Erik Janssen. - ATTENTION: The information in this electronic mail message is private and confidential, and only intended for the addressee. Should you receive this message by mistake, you are hereby notified that any disclosure, reproduction, distribution or use of this message is strictly prohibited. Please inform the sender by reply transmission and delete the message without copying or opening it. Messages and attachments are scanned for all viruses known. If this message contains password-protected attachments, the files have NOT been scanned for viruses by the ING mail domain. Always scan attachments before opening them. - -- 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: TSO region size
It seems, that the tso-programmers reserved only 3 Bytes for this field. Normally the hex 0-7FF (are positive numbers) FFF-800 (are negative numbers). But i dont know anybody who needs more than 512 MB. And this only for starting java applications in the own region. Regards, Alexander -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Erik Janssen Sent: Tuesday, June 29, 2010 4:08 PM To: IBM-MAIN@bama.ua.edu Subject: TSO region size Hello List, We are standardising our default TSO region sizes on 64MB since we start seeing more and more problems with programs abending, because people still have 4MB region size as a default. 64MB seemed like a reasonable value to solve some of the issues and not introduce any new. Testing the changes I noticed when I log on to TSO the help panel says that the maximum possible region size is 2096128. This is 1 MB less than 2 GB, which would be 2097152. Can somebody tell me why the max is not exactly 2GB? Regards, Erik Janssen. - ATTENTION: The information in this electronic mail message is private and confidential, and only intended for the addressee. Should you receive this message by mistake, you are hereby notified that any disclosure, reproduction, distribution or use of this message is strictly prohibited. Please inform the sender by reply transmission and delete the message without copying or opening it. Messages and attachments are scanned for all viruses known. If this message contains password-protected attachments, the files have NOT been scanned for viruses by the ING mail domain. Always scan attachments before opening them. - -- 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: TSO region size
-Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Riedel, Alexander Sent: Tuesday, June 29, 2010 9:24 AM To: IBM-MAIN@bama.ua.edu Subject: Re: TSO region size It seems, that the tso-programmers reserved only 3 Bytes for this field. Normally the hex 0-7FF (are positive numbers) FFF-800 (are negative numbers). But i dont know anybody who needs more than 512 MB. And this only for starting java applications in the own region. Regards, Alexander Hum, my TSO region size is: 2,096,128 (aka 2G). Of course, I likely don't __need__ this. But I do OMVS work and it seems to help. TSO INFORMATION --- ACCTNUM= H0I DEST= LOCAL HOLDCLASS= X MSGCLASS= X PROC= $TSPDFT SIZE= 02096128 MAXSIZE= 02096128 SYSOUTCLASS= X USERDATA= COMMAND= -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * (817)-961-6183 cell john.mck...@healthmarkets.com * www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM -- 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: TSO region size
2G = 2,000,000,000 2Gi = 2,147,483,648 Where is 2Gi a documented standard, other than IBM-Main? This is as pedantic as the 'true meaning' of USS. To me, 2048M is 2G, and when it's on disk, 2000M is 2G. That was the distinction taught in University in the 1970's. This is a nit. - I'm a SuperHero with neither powers, nor motivation! SHAZAM! -- 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: TSO region size
-Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Ted MacNEIL Sent: Tuesday, June 29, 2010 10:28 AM To: IBM-MAIN@bama.ua.edu Subject: Re: TSO region size 2G = 2,000,000,000 2Gi = 2,147,483,648 Where is 2Gi a documented standard, other than IBM-Main? This is as pedantic as the 'true meaning' of USS. To me, 2048M is 2G, and when it's on disk, 2000M is 2G. That was the distinction taught in University in the 1970's. This is a nit. - Closest I can find: http://physics.nist.gov/cuu/Units/binary.html -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * (817)-961-6183 cell john.mck...@healthmarkets.com * www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM -- 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: TSO region size
On Tue, 29 Jun 2010 15:27:41 +, Ted MacNEIL wrote: 2G = 2,000,000,000 2Gi = 2,147,483,648 Where is 2Gi a documented standard, other than IBM-Main? http://physics.nist.gov/cuu/Units/binary.html In December 1998 the International Electrotechnical Commission (IEC), the leading international organization for worldwide standardization in electrotechnology, approved as an IEC International Standard names and symbols for prefixes for binary multiples for use in the fields of data processing and data transmission. ... Perhaps this hasn't reached Canada, yet. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: TSO region size
-Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Paul Gilmartin Sent: Tuesday, June 29, 2010 9:59 AM To: IBM-MAIN@bama.ua.edu Subject: Re: TSO region size On Tue, 29 Jun 2010 09:40:52 -0500, McKown, John wrote: Hum, my TSO region size is: 2,096,128 (aka 2G). Of course, I likely don't __need__ this. But I do OMVS work and it seems to help. Ummm. My calculator shows: 2G = 2,000,000,000 2Gi = 2,147,483,648 And: 504 $ factor 2096128 Factors of 2096128 are 2 2 2 2 2 2 2 2 2 2 23 89 which appears not to be 2G or 2Gi in either decimal or binary conventions. --gil picky, picky, picky. -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * (817)-961-6183 cell john.mck...@healthmarkets.com * www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM -- 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
