Re: Region size for OMVS tasks
Hello Peter Problem solved! Your idea(s) regarding the SMF30 record analysis eventually led me to reproducing the test environment used by the developer so that I could run the tests myself. One look at the command being used showed what the problem was - there was a parametrised upper limit of 768M on the memory to be used. The developer had completely missed this information. Bumping the parm value to 1G was enough to get the test through, but I'm still arguing for all such limits to be removed - "let the system sort itself out, don't try and 'second guess' things..." Such a simple thing, spotted by a different set of eyes being used, but that's frequently the root cause in problems such as this, I find. Also, your comment about chopping columns off the REXXSTOR output showed that I was using an old version of Mark's work. That has been addressed. Thank you very much for all your efforts and input on this. I really appreciate it. Regards Sean On Fri, 23 Nov 2018 at 06:35, Peter Hunkeler wrote: > > > One more thought: Look At he SMF30 records for one such session. You > should get an idea of what‘s going on in that process and its child > processes. There will be one record for each command, i.e. when a fork()ed > or spawd()ed process ends, and at each exec(). You may find the one program > eating up all that storage. > > > — > Peter Hunkeler > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Region size for OMVS tasks
Sean Gleann wrote: >Hello Peter >Problem solved! Excellent. Thanks to Peter Hunkeler. >Your idea(s) regarding the SMF30 record analysis eventually led me to >reproducing the test environment used by the developer so that I could run the >tests myself. This is what IBM (and other vendors) also does and recommends. Try to reproduce the problem yourself. >One look at the command being used showed what the problem was - there was a >parametrised upper limit of 768M on the memory to be used. The developer had >completely missed this information. Bumping the parm value to 1G was enough to >get the test through, Ouch! So despite all the tuning and resizing attempts, it was the application itself which restrict itself too much using a too small value... >... but I'm still arguing for all such limits to be removed - "let the system >sort itself out, don't try and 'second guess' things..." >Such a simple thing, spotted by a different set of eyes being used, but that's >frequently the root cause in problems such as this, I find. Agreed! I also find that some weird problems are caused by our clients who develop their own applications. Sometimes I recommend - backout changes - attempt to recreate the problem - voila, problem resolved. Groete / Greetings Elardus Engelbrecht -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Region size for OMVS tasks
1. A different set of eyes is always an asset 2. Sometimes when I explain a problem to a different set of eyes I see the solution myself; there seems to be a psychological difference between explaining something and analyzing it 3. If you can reproduce the problem, that helps; if you can reproduce it with instrumentation turned on, you're hallway to a solution. 4. Check your assumptions, especially about version control. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of Sean Gleann Sent: Monday, November 26, 2018 6:14 AM To: IBM-MAIN@listserv.ua.edu Subject: Re: Region size for OMVS tasks Hello Peter Problem solved! Your idea(s) regarding the SMF30 record analysis eventually led me to reproducing the test environment used by the developer so that I could run the tests myself. One look at the command being used showed what the problem was - there was a parametrised upper limit of 768M on the memory to be used. The developer had completely missed this information. Bumping the parm value to 1G was enough to get the test through, but I'm still arguing for all such limits to be removed - "let the system sort itself out, don't try and 'second guess' things..." Such a simple thing, spotted by a different set of eyes being used, but that's frequently the root cause in problems such as this, I find. Also, your comment about chopping columns off the REXXSTOR output showed that I was using an old version of Mark's work. That has been addressed. Thank you very much for all your efforts and input on this. I really appreciate it. Regards Sean On Fri, 23 Nov 2018 at 06:35, Peter Hunkeler wrote: > > > One more thought: Look At he SMF30 records for one such session. You > should get an idea of what‘s going on in that process and its child > processes. There will be one record for each command, i.e. when a fork()ed > or spawd()ed process ends, and at each exec(). You may find the one program > eating up all that storage. > > > — > Peter Hunkeler > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Region size for OMVS tasks
Sorry for not coming back earlier - a minor panic at this end took precedence… Elardus: "...despite all the tuning and resizing attempts, it was... " Precisely so. No matter what I did at the global level, the developer was overriding with his own specification. He had completely missed the significance of the string '768M' in his command, and I had not been party to actually running the test. In the event, the developer sent me a screen shot that showed both the REXXSTOR output *and* the command text. One look from my 'different set of eyes' was enough to crack the problem. Seymour: I've often considered the idea of a simple cardboard cut-out of a figure - not necessarily human! - mounted on a spring such that it appears to nod or shake it's head as it bounces. Place this 'device' on your desk beside you as you perform a personalised 'walk-through' of your problem program, and I'm fairly certain that the time taken for problem determination and source identification would be at least halved... One day I'll get around to making such a thing. Regards Sean On Mon, 26 Nov 2018 at 19:21, Seymour J Metz wrote: > 1. A different set of eyes is always an asset > > 2. Sometimes when I explain a problem to a different set of eyes I see > the solution myself; > there seems to be a psychological difference between explaining > something and analyzing it > > 3. If you can reproduce the problem, that helps; if you can reproduce it > with instrumentation > turned on, you're hallway to a solution. > > 4. Check your assumptions, especially about version control. > > > -- > Shmuel (Seymour J.) Metz > http://mason.gmu.edu/~smetz3 > > > From: IBM Mainframe Discussion List on behalf > of Sean Gleann > Sent: Monday, November 26, 2018 6:14 AM > To: IBM-MAIN@listserv.ua.edu > Subject: Re: Region size for OMVS tasks > > Hello Peter > Problem solved! > Your idea(s) regarding the SMF30 record analysis eventually led me to > reproducing the test environment used by the developer so that I could run > the tests myself. > One look at the command being used showed what the problem was - there was > a parametrised upper limit of 768M on the memory to be used. The > developer had completely missed this information. Bumping the parm value to > 1G was enough to get the test through, but I'm still arguing for all such > limits to be removed - "let the system sort itself out, don't try and > 'second guess' things..." > > Such a simple thing, spotted by a different set of eyes being used, but > that's frequently the root cause in problems such as this, I find. > > Also, your comment about chopping columns off the REXXSTOR output showed > that I was using an old version of Mark's work. That has been addressed. > > Thank you very much for all your efforts and input on this. I really > appreciate it. > > Regards > Sean > > On Fri, 23 Nov 2018 at 06:35, Peter Hunkeler wrote: > > > > > > > One more thought: Look At he SMF30 records for one such session. You > > should get an idea of what‘s going on in that process and its child > > processes. There will be one record for each command, i.e. when a > fork()ed > > or spawd()ed process ends, and at each exec(). You may find the one > program > > eating up all that storage. > > > > > > — > > Peter Hunkeler > > > > -- > > For IBM-MAIN subscribe / signoff / archive access instructions, > > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Region size for OMVS tasks
On 11/21/2018 11:39 AM, Jackson, Rob wrote: This is what standalone restore is for, Sean. But if you don't have one built, you could try this: http://www.cbttape.org/~jjaeger/zzsa.html. I've used it before but not on anything more recent than a z10. If it will IPL, you can find your IEFUSI module and make it like IEFBR14. I tried it a coupla months ago on our z13s. Worked great! -- Phoenix Software International Edward E. Jaffe 831 Parkview Drive North El Segundo, CA 90245 https://www.phoenixsoftware.com/ This e-mail message, including any attachments, appended messages and the information contained therein, is for the sole use of the intended recipient(s). If you are not an intended recipient or have otherwise received this email message in error, any use, dissemination, distribution, review, storage or copying of this e-mail message and the information contained therein is strictly prohibited. If you are not an intended recipient, please contact the sender by reply e-mail and destroy all copies of this email message and do not otherwise utilize or retain this email message or any or all of the information contained therein. Although this email message and any attachments or appended messages are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by the sender for any loss or damage arising in any way from its opening or use. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Region size for OMVS tasks
On 11/26/2018 3:14 AM, Sean Gleann wrote: ... Bumping the parm value to 1G was enough to get the test through, but I'm still arguing for all such limits to be removed - "let the system sort itself out, don't try and 'second guess' things..." Haha! Remove all memory constraints and take bets to see who gets fired first when some pimply-faced college kid with a sense of humor submits this tiny program just to see if the "fabled" mainframe is as resilient as people claim... LOL //SEANFUN JOB 1,SEANFUN,CLASS=A,MSGCLASS=T,MEMLIMIT=NOLIMIT,TIME=NOLIMIT //STEPLIB DD DSN=SEAN.TEST.LOAD,DISP=SHR // EXEC PGM=SEANFUN // SEANFUN CSECT , SEANFUN AMODE 64 SEANFUN RMODE 31 LARL 12,SEANFUN USING SEANFUN,12 IARV64 REQUEST=GETSTOR, Request boatloads TYPE=PAGEABLE, .Pageable storage SEGMENTS=Segments, .Number of 1M pages PAGEFRAMESIZE=PAGEABLE1MEG, Prefer 1M frames ORIGIN=Origin .Return address location LG 0,Origin Point to storage LG 1,Segments Compute its length SLAG 1,1,20 (same) LA 14,Message Point to fun message LGHI 15,L'Message Get message length COPYFUN MVCLE 0,14,C' ' Copy fun message JO COPYFUN (same) DC H'0' <-- haha! it's doubtful this halfword will * be executed in any z/OS system in the * world. but, if it ever does, it will * die with an 0C1! LOL Origin DC AD(0) Segments DC AD(X'0FFF') Message DC C'What Now, Bruh? LOL' END SEANFUN -- Phoenix Software International Edward E. Jaffe 831 Parkview Drive North El Segundo, CA 90245 https://www.phoenixsoftware.com/ This e-mail message, including any attachments, appended messages and the information contained therein, is for the sole use of the intended recipient(s). If you are not an intended recipient or have otherwise received this email message in error, any use, dissemination, distribution, review, storage or copying of this e-mail message and the information contained therein is strictly prohibited. If you are not an intended recipient, please contact the sender by reply e-mail and destroy all copies of this email message and do not otherwise utilize or retain this email message or any or all of the information contained therein. Although this email message and any attachments or appended messages are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by the sender for any loss or damage arising in any way from its opening or use. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Region size for OMVS tasks
(X) <== LIKE button Cool answer! (Did not try it at home) It reminds me of back in my Waterloony days, experiments with unforeseen consequences. At worst, only temporarily revoked, not fired! (being a student) Thanks, Mike Baldwin Cartagena Software Limited Markham, Ontario, Canada https://cartagena.com +1 905-887-0755 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Region size for OMVS tasks
On 12/21/2018 9:50 AM, Mike Baldwin wrote: (X) <== LIKE button Cool answer! (Did not try it at home) It reminds me of back in my Waterloony days, experiments with unforeseen consequences. At worst, only temporarily revoked, not fired! (being a student) Haha! I tried it just to be sure it had the desired effect. It did... ;-) -- Phoenix Software International Edward E. Jaffe 831 Parkview Drive North El Segundo, CA 90245 https://www.phoenixsoftware.com/ This e-mail message, including any attachments, appended messages and the information contained therein, is for the sole use of the intended recipient(s). If you are not an intended recipient or have otherwise received this email message in error, any use, dissemination, distribution, review, storage or copying of this e-mail message and the information contained therein is strictly prohibited. If you are not an intended recipient, please contact the sender by reply e-mail and destroy all copies of this email message and do not otherwise utilize or retain this email message or any or all of the information contained therein. Although this email message and any attachments or appended messages are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by the sender for any loss or damage arising in any way from its opening or use. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Region size for OMVS tasks
Might want to look at ULIMIT in .profile, UNIX System Services Command Reference -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Sean Gleann Sent: Monday, November 19, 2018 8:51 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: [EXTERNAL] Region size for OMVS tasks We have a problem here that is proving to be … um... "resistant to analysis" & I wonder if anyone on this list might be able to help. Most of our developers submit work to the system from a PuTTY session, that will result in multiple OMVS tasks being fork()ed or spawn()ed. Of late, such work has been failing with messages: IEW4000I FETCH FOR MODULE FROM DDNAME SYS00061 FAILED BECAUSE INSUFFICIENT STORAGE WAS AVAILABLE. - and - CSV031I LIBRARY ACCESS FAILED FOR MODULE , RETURN CODE 14, REASON CODE 26110021, DDNAME SYS00061 which basically, as far as I can make out, mean that my region size is too small. But these are OMVS tasks, where a REGION size specification isn't allowed for. If I look at the type-30 records for the failing tasks, I see that the 'region requested' value is 54M in each case. We don 't have any SMFLIMxx member defined, so there's nothing coming from there, since that PARMLIB member *must* be defined if it is to be used - there are no defaults. Our IEFUSI is the default 'stub' supplied with the BCP i.e. all it does is the equivalent of a 'BR 14', so that isn't limiting anything either. So where is that 54M value coming from? How can I modify it? Regards Sean -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Region size for OMVS tasks
do you have a MEMLIMIT in the SMFPRMxx member ? Carmen Vitullo - Original Message - From: "Sean Gleann" To: IBM-MAIN@LISTSERV.UA.EDU Sent: Monday, November 19, 2018 7:51:04 AM Subject: Region size for OMVS tasks We have a problem here that is proving to be … um... "resistant to analysis" & I wonder if anyone on this list might be able to help. Most of our developers submit work to the system from a PuTTY session, that will result in multiple OMVS tasks being fork()ed or spawn()ed. Of late, such work has been failing with messages: IEW4000I FETCH FOR MODULE FROM DDNAME SYS00061 FAILED BECAUSE INSUFFICIENT STORAGE WAS AVAILABLE. - and - CSV031I LIBRARY ACCESS FAILED FOR MODULE , RETURN CODE 14, REASON CODE 26110021, DDNAME SYS00061 which basically, as far as I can make out, mean that my region size is too small. But these are OMVS tasks, where a REGION size specification isn't allowed for. If I look at the type-30 records for the failing tasks, I see that the 'region requested' value is 54M in each case. We don 't have any SMFLIMxx member defined, so there's nothing coming from there, since that PARMLIB member *must* be defined if it is to be used - there are no defaults. Our IEFUSI is the default 'stub' supplied with the BCP i.e. all it does is the equivalent of a 'BR 14', so that isn't limiting anything either. So where is that 54M value coming from? How can I modify it? Regards Sean -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Region size for OMVS tasks
Check MAXASSIZE in BPXPRMxx Check Check ASSIZEMAX and MEMLIMT in the OMVS segment for the UID in question HTH, -Original Message- From: IBM Mainframe Discussion List On Behalf Of Carmen Vitullo Sent: Monday, November 19, 2018 8:03 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Region size for OMVS tasks do you have a MEMLIMIT in the SMFPRMxx member ? Carmen Vitullo - Original Message - From: "Sean Gleann" To: IBM-MAIN@LISTSERV.UA.EDU Sent: Monday, November 19, 2018 7:51:04 AM Subject: Region size for OMVS tasks We have a problem here that is proving to be … um... "resistant to analysis" & I wonder if anyone on this list might be able to help. Most of our developers submit work to the system from a PuTTY session, that will result in multiple OMVS tasks being fork()ed or spawn()ed. Of late, such work has been failing with messages: IEW4000I FETCH FOR MODULE FROM DDNAME SYS00061 FAILED BECAUSE INSUFFICIENT STORAGE WAS AVAILABLE. - and - CSV031I LIBRARY ACCESS FAILED FOR MODULE , RETURN CODE 14, REASON CODE 26110021, DDNAME SYS00061 which basically, as far as I can make out, mean that my region size is too small. But these are OMVS tasks, where a REGION size specification isn't allowed for. If I look at the type-30 records for the failing tasks, I see that the 'region requested' value is 54M in each case. We don 't have any SMFLIMxx member defined, so there's nothing coming from there, since that PARMLIB member *must* be defined if it is to be used - there are no defaults. Our IEFUSI is the default 'stub' supplied with the BCP i.e. all it does is the equivalent of a 'BR 14', so that isn't limiting anything either. So where is that 54M value coming from? How can I modify it? Regards Sean -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ::DISCLAIMER:: -- The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. E-mail transmission is not guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or may contain viruses in transmission. The e mail and its contents (with or without referred errors) shall therefore not attach any liability on the originator or HCL or its affiliates. Views or opinions, if any, presented in this email are solely those of the author and may not necessarily reflect the views or opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of authorized representative of HCL is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any email and/or attachments, please check them for viruses and other defects. -- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Region size for OMVS tasks
None of the suggestions so far check out, unfortunately. David: all limits associated with memory come back as 'Unlimited' Carmen: Yes, I've got MEMLIMIT(1280M) specified Alan: BPXPRMxx MAXASSIZE is set to 2G, and the OMVS segment ASSIZEMAX and MEMLIMT values are not specified, so they default to something. Hmmm that may be a way forward - play with one or both those settings to see what happens. I'll let you know how my testing pans out. Thank you, gentlemen. Sean On Mon, 19 Nov 2018 at 14:25, Allan Staller wrote: > Check MAXASSIZE in BPXPRMxx > Check Check ASSIZEMAX and MEMLIMT in the OMVS segment for the UID in > question > > HTH, > > -Original Message- > From: IBM Mainframe Discussion List On Behalf > Of Carmen Vitullo > Sent: Monday, November 19, 2018 8:03 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Region size for OMVS tasks > > do you have a MEMLIMIT in the SMFPRMxx member ? > > > > Carmen Vitullo > > - Original Message - > > From: "Sean Gleann" > To: IBM-MAIN@LISTSERV.UA.EDU > Sent: Monday, November 19, 2018 7:51:04 AM > Subject: Region size for OMVS tasks > > We have a problem here that is proving to be … um... "resistant to > analysis" & I wonder if anyone on this list might be able to help. > > Most of our developers submit work to the system from a PuTTY session, > that will result in multiple OMVS tasks being fork()ed or spawn()ed. Of > late, such work has been failing with messages: > IEW4000I FETCH FOR MODULE FROM DDNAME SYS00061 FAILED BECAUSE > INSUFFICIENT STORAGE WAS AVAILABLE. > - and - > CSV031I LIBRARY ACCESS FAILED FOR MODULE , RETURN CODE 14, REASON > CODE 26110021, DDNAME SYS00061 which basically, as far as I can make out, > mean that my region size is too small. > > But these are OMVS tasks, where a REGION size specification isn't allowed > for. > If I look at the type-30 records for the failing tasks, I see that the > 'region requested' value is 54M in each case. > We don 't have any SMFLIMxx member defined, so there's nothing coming from > there, since that PARMLIB member *must* be defined if it is to be used - > there are no defaults. > Our IEFUSI is the default 'stub' supplied with the BCP i.e. all it does is > the equivalent of a 'BR 14', so that isn't limiting anything either. > So where is that 54M value coming from? How can I modify it? > > Regards > Sean > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, send email > to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, send email > to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > ::DISCLAIMER:: > > -- > The contents of this e-mail and any attachment(s) are confidential and > intended for the named recipient(s) only. E-mail transmission is not > guaranteed to be secure or error-free as information could be intercepted, > corrupted, lost, destroyed, arrive late or incomplete, or may contain > viruses in transmission. The e mail and its contents (with or without > referred errors) shall therefore not attach any liability on the originator > or HCL or its affiliates. Views or opinions, if any, presented in this > email are solely those of the author and may not necessarily reflect the > views or opinions of HCL or its affiliates. Any form of reproduction, > dissemination, copying, disclosure, modification, distribution and / or > publication of this message without the prior written consent of authorized > representative of HCL is strictly prohibited. If you have received this > email in error please delete it and notify the sender immediately. Before > opening any email and/or attachments, please check them for viruses and > other defects. > > -- > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Region size for OMVS tasks
Sean Gleann wrote: >None of the suggestions so far check out, unfortunately. >David: all limits associated with memory come back as 'Unlimited' >Carmen: Yes, I've got MEMLIMIT(1280M) specified >Alan: BPXPRMxx MAXASSIZE is set to 2G, and the OMVS segment ASSIZEMAX and >MEMLIMT values are not specified, so they default to something. >Hmmm that may be a way forward - play with one or both those settings to see >what happens. Check out your OMVS segment in RACF. AFAIK - RACF overrides nearly everything above. Increase these in RACF these parts in the OMVS segment: ASSIZEMAX, FILEPROCMAX, PROCUSERMAX, THREADSMAX, MMAPAREAMAX I know you said ASSIZEMAX, but just set it and increase it (in large chunks). Let us know what your solution is. Good luck! Groete / Greetings Elardus Engelbrecht -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Region size for OMVS tasks
Interesting stuff, here... Before making any changes, analysis of the type-30 data showed SMF30RGN=56623104 (54M) and SMF30MES - the source of MEMLIT - as '1', which apparently means that MEMLIMIT is set by SMF. Also, SMF30MEM was coming back as 1280M - the same as the MEMLIMIT in SMFPRMxx. So far, so good. So I set the ASSIZEMAX for my own profile to 2G and logged off-n-on. No change in the type-30 values Then I set the associated MEMLIMIT value to 2G & logged off and on again. This time, SMF30MEM is coming back as 2048M. Great! I can modify the MEMLIMIT value and perhaps solve my problem. I'll have to re-engage one of the developers for that, could take a bit of time. But a curiosity has cropped up along the way... Now, my SMF30MES is coming back as '5' - which is undocumented, according to the System Management Facilities manual I'm using (SA22-7630-26 - which I believe is the latest, though I stand to be corrected). Apparently, the values for SMF30MES can be one of 1, 2, 3, 4 or 10 (decimal), so where the '5' is coming from is a mystery. I'm not sure it's important and I shan't chase it up with IBM, but thought it worth mentioning. Sean On Mon, 19 Nov 2018 at 15:38, Elardus Engelbrecht < elardus.engelbre...@sita.co.za> wrote: > Sean Gleann wrote: > > >None of the suggestions so far check out, unfortunately. > >David: all limits associated with memory come back as 'Unlimited' > >Carmen: Yes, I've got MEMLIMIT(1280M) specified > >Alan: BPXPRMxx MAXASSIZE is set to 2G, and the OMVS segment ASSIZEMAX and > >MEMLIMT values are not specified, so they default to something. > >Hmmm that may be a way forward - play with one or both those settings to > see what happens. > > Check out your OMVS segment in RACF. AFAIK - RACF overrides nearly > everything above. > > Increase these in RACF these parts in the OMVS segment: ASSIZEMAX, > FILEPROCMAX, PROCUSERMAX, THREADSMAX, MMAPAREAMAX > > I know you said ASSIZEMAX, but just set it and increase it (in large > chunks). > > Let us know what your solution is. Good luck! > > Groete / Greetings > Elardus Engelbrecht > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Region size for OMVS tasks
strange, the latest doc I have show's these values for SMF30MES Value Meaning X'01' MEMLIMIT set by SMF. X'02' MEMLIMIT set explicitly in the JCL with MEMLIMIT parameter on JOB or EXEC statement. X'03' MEMLIMIT is unlimited based on REGION=0 specification. X'04' MEMLIMIT set by IEFUSI (even if IEFUSI did not change the value). X'0A' System provided a default for MEMLIMIT based on REGION=0 specification and a subsequent curtailment of REGION in the IEFUSI exit. Carmen Vitullo - Original Message - From: "Sean Gleann" To: IBM-MAIN@LISTSERV.UA.EDU Sent: Monday, November 19, 2018 10:12:18 AM Subject: Re: Region size for OMVS tasks Interesting stuff, here... Before making any changes, analysis of the type-30 data showed SMF30RGN=56623104 (54M) and SMF30MES - the source of MEMLIT - as '1', which apparently means that MEMLIMIT is set by SMF. Also, SMF30MEM was coming back as 1280M - the same as the MEMLIMIT in SMFPRMxx. So far, so good. So I set the ASSIZEMAX for my own profile to 2G and logged off-n-on. No change in the type-30 values Then I set the associated MEMLIMIT value to 2G & logged off and on again. This time, SMF30MEM is coming back as 2048M. Great! I can modify the MEMLIMIT value and perhaps solve my problem. I'll have to re-engage one of the developers for that, could take a bit of time. But a curiosity has cropped up along the way... Now, my SMF30MES is coming back as '5' - which is undocumented, according to the System Management Facilities manual I'm using (SA22-7630-26 - which I believe is the latest, though I stand to be corrected). Apparently, the values for SMF30MES can be one of 1, 2, 3, 4 or 10 (decimal), so where the '5' is coming from is a mystery. I'm not sure it's important and I shan't chase it up with IBM, but thought it worth mentioning. Sean On Mon, 19 Nov 2018 at 15:38, Elardus Engelbrecht < elardus.engelbre...@sita.co.za> wrote: > Sean Gleann wrote: > > >None of the suggestions so far check out, unfortunately. > >David: all limits associated with memory come back as 'Unlimited' > >Carmen: Yes, I've got MEMLIMIT(1280M) specified > >Alan: BPXPRMxx MAXASSIZE is set to 2G, and the OMVS segment ASSIZEMAX and > >MEMLIMT values are not specified, so they default to something. > >Hmmm that may be a way forward - play with one or both those settings to > see what happens. > > Check out your OMVS segment in RACF. AFAIK - RACF overrides nearly > everything above. > > Increase these in RACF these parts in the OMVS segment: ASSIZEMAX, > FILEPROCMAX, PROCUSERMAX, THREADSMAX, MMAPAREAMAX > > I know you said ASSIZEMAX, but just set it and increase it (in large > chunks). > > Let us know what your solution is. Good luck! > > Groete / Greetings > Elardus Engelbrecht > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Region size for OMVS tasks
SYS1.MODGEN(IARRAX) RAXLVMEMLIMS DS CL1 Source of Address Space memory limit. *When RaxLvMemLimS=RAXLVUSI and *RAX_SMFLIMRas is 0, IEFUSI set the *MEMLIMIT. When RaxLvMemLimS=RAXLVUSI and *RAX_SMFLIMRas is non-zero, RAX_SMFLIMRas *contains info about the setting of *RaxLvMemlimit.@0DC RAXLVSMF EQU 1 MEMLIMIT set by SMF either in SMFPRMxx *or by use of SMF default value=0 @PHC RAXLVJCL EQU 2 MEMLIMIT set by the JCL @PHC RAXLVREG0EQU 3 MEMLIMIT Unlimited based on *REGION=0 specification@PHC RAXLVUSI EQU 4 MEMLIMIT set by IEFUSI@PHC RAXLVOMVSEQU 5 MEMLIMIT set by UNIX OMVS segment @PHC RAXLVSETREQU 6 MEMLIMIT set by UNIX setrlimit@PHC RAXLVSPW EQU 7 MEMLIMIT set by UNIX spawn@PHC RAXLVSETOEQU 8 MEMLIMIT set by UNIX *SETOMVS command @PHC RAXLVAUTHEQU 9 MEMLIMIT set by authorized *application modification @PHC RAXLVURG EQU 10 Special case of MEMLIMIT *getting set in IEFSMFIE *(IEFUSI set REGION size) @PHC Jim Mulder z/OS Diagnosis, Design, Development, Test IBM Corp. Poughkeepsie NY "IBM Mainframe Discussion List" wrote on 11/19/2018 11:12:18 AM: > From: "Sean Gleann" > To: IBM-MAIN@LISTSERV.UA.EDU > Date: 11/19/2018 04:28 PM > Subject: Re: Region size for OMVS tasks > Sent by: "IBM Mainframe Discussion List" > > Interesting stuff, here... > Before making any changes, analysis of the type-30 data showed > SMF30RGN=56623104 (54M) and SMF30MES - the source of MEMLIT - as '1', which > apparently means that MEMLIMIT is set by SMF. Also, SMF30MEM was coming > back as 1280M - the same as the MEMLIMIT in SMFPRMxx. So far, so good. > So I set the ASSIZEMAX for my own profile to 2G and logged off-n-on. No > change in the type-30 values > Then I set the associated MEMLIMIT value to 2G & logged off and on again. > This time, SMF30MEM is coming back as 2048M. Great! I can modify the > MEMLIMIT value and perhaps solve my problem. I'll have to re-engage one of > the developers for that, could take a bit of time. > But a curiosity has cropped up along the way... > Now, my SMF30MES is coming back as '5' - which is undocumented, according > to the System Management Facilities manual I'm using (SA22-7630-26 - which > I believe is the latest, though I stand to be corrected). Apparently, the > values for SMF30MES can be one of 1, 2, 3, 4 or 10 (decimal), so where the > '5' is coming from is a mystery. I'm not sure it's important and I shan't > chase it up with IBM, but thought it worth mentioning. > > Sean -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Region size for OMVS tasks
Thanks for the responses, gents Carmen: yes - that is what I see in the manual Jim: Thanks for the update - it would appear that the manual requires an update Peter: I'm still trying to fully assimilate what you've said - very detailed & complete. Where did you get all this from? Is it documented somewhere, or is it something you've 'soaked up through your fingertips' over the years? I have to say that even after 40 years on mainframes I still don't fully understand this kind of memory-associated stuff I can understand that it's rooted in the past when 'memory' was expensive so it had to be protected from over-commitment. These days, though, I find it next to impossible to justify insufficient physical memory; it's so cheap (comparatively speaking), there's just no excuse. Even if your environment is thus limited then paging to/from disks on a RAID array removes most of any remaining constraints. Given that (probably poorly-informed) stance, then REGION and MEMLIMIT limits become pretty much meaningless. Don't they? Regards Sean On Tue, 20 Nov 2018 at 07:49, Peter Hunkeler wrote: > > > From fading memory, so things might have change slightly, but I think most > of this still applies. > > > The REGION and MEMLIMIT values that apply to z/OS UNIX processes depend on > how and where the process is running: > > > a) BATCH jobs, started tasks, TSO user sessions > A program run as batch job, started task, or in a TSO session gets its > REGION and MEMLIMIT via JCL, which may be changed by IEFUSI (and IEFLIMIT). > When this program makes use of z/OS UNIX services, it will become dubbed, > i.e. it becomes a UINX process. It still runs in the same address space. > Nothing changes with respect to REGION or MEMLIMT. > > > When this process spawn()s (non-local spawn) or fork()s a new process, > that new process will be in a BPXAS address space. REGION and MEMLIMT will > be inherited from the originating batch job address space. None of the z/OS > UNIX settings apply. > > > IEFUSI will gin control in the BPXAS address space before the UNIX process > gets control. OMVS set REGION to the magic value 54M. This has not meaning > and will later be replaced by the values from the originating batch job. (I > don‘t know why 54M was chosen as the indicator value.) > > > b) If a z/OS UNIX process is a daemon, such as FTPD, otelnetd, etc. which > listens for incoming session calls, then authenticates the new user, and > spawn()s / fork()s a new process for this new user, then REGION and > MEMLIMIT will be set from the z/OS UNIX parameters (ASSIZEMAX/MAXASSIZE, > etc). It is not useful to inherit those values from the parent process in > these cases. The parent is the server, the childs are the unser sessions. > They serve different means. > > > So, your IEFUSI should not touch the REGION and MEMLIMIT field when it is > called for OMVS address spaces (see flags as described in the IEFUSI > description). And, for the putty sessions, the MAXASSIZE or ASSIZEMAX value > should apply. Try to run Mark Zelden‘s REXXSTOR in a TSO session, after TSO > OMVS, and in a putty session to see the differences > > > From the „z/OS MVs Installation Exits“ manual: > Additional Considerations for z/OS UNIX Applications: > When running z/OS UNIX applications you need to consider that fork and > spawn are issued to create new address spaces. The default processing on > fork and spawn is for the z/OS UNIX kernel to propagate the region size > from the parent to the child. Because the region size in the parent process > has already passed through IEFUSI and has an approved region size, IBM > recommends that you bypass normal IEFUSI processing when the subsystem > (Word 8) is OMVS. > > > At the time of IEFUSI processing, the kernel has not yet propagated the > parent's region size to the child, so IEFUSI has nothing to work with. If > IEFUSI modifies the region size of the child process, the kernel will honor > that region size and not propagate the region size from parent to child. > This can result in failure of a fork if the region size is insufficient in > the child to capture the parent's storage. > > > -- > Peter Hunkeler > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Region size for OMVS tasks
For an LPAR, you should have enough dasd to back real memory. To take a system dump, you need to copy the memory and the paging. So you need 3X the amount of real memory. If paging on any LPAR is over 30%, you should be reducing usage or adding space. On Tue, Nov 20, 2018 at 6:02 AM Peter Hunkeler wrote: > > > > >Peter: I'm still trying to fully assimilate what you've said - very > detailed & complete. Where did you get all this from? Is it documented > somewhere, or is it something you've 'soaked up through your fingertips' > over the years? > > > I pasted one section which is one part of the „documented somewhere“. There > is probably more parts that are documents, but I was too lazy to seek them > all. So it‘s comes to „soaked up through your fingertips“, or better > „discussing on fora“ and soaking up though the eyes :-) > > > I‘ve been following and teaching z/OS UNIX for a couple of years when it came > out in 1994. A lot has been discussed, and tested back then. That is why I > wrote 2fading memory“. I haven‘t been following changes to z/OS UNIX as close > as I used to. > > > > > >Given that (probably poorly-informed) stance, then REGION and MEMLIMIT > limits become pretty much meaningless. Don't they? > > > > > I‘m can agree regarding REGION; I do not regarding MEMLIMIT. I‘m convinced a > program going wild using 64bit memory can bring the system down in no time, > if it is *not* limited to a reason amount. > > > Remember: Even though a z13, or a z14 can have up to 10TiB, or 32TiB of real > memory installed, z/OS V2.2, and V2.3 can only support up to 4TiB. 4TiB is > nothing compared to 16EiB (the full 64bit addressing range). Storage finally > needs to be backed by real storage. And, real storage needs to be backed by > paging storage (virtual flash memory or paging DASD). Given the fact that the > largest supported DASD EAV volume is 1TiB now, you would need 16.8 Million > 1TiB paging devices to be able to back one single 64bit address space. > > > From experience I know that programs *do* eventually go wild. Better protect > your system with a low MEMLIMIT, and allow larges values only sparingly. My > $0.02 only, of course. > > > — > Peter Hunkeler > > > > > > > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- 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...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Region size for OMVS tasks
Where did you get all this from? Is it documented somewhere, or is it something you've 'soaked up through your fingertips' over the years? So I went back to the FMs. For any question of kind "How does that UNIX service behave regarding MVS resources, attributes, etc.", I always read what the "z/OS UNIX System Services Programming - Assembler Callable Services Reference" tells me. If something is to be said, there is a section called "Usage Notes". Here are some interesting snippet: For fork() it says: - The child process inherits the MEMLIMIT of the parent. - The child address space inherits the following address space attributes of the parent address space: region size and time limit. For spawn() it says: - The region size of the parent is inherited by the child, unless the INHESETREGIONSZ flag in the inheritance structure is set on to indicate that the value specified in INHEREGIONSZ is to be used to determine the child's region size. For more information, see What are soft limits? in z/OS UNIX System Services Planning and Inheriting soft limits in z/OS UNIX System Services Planning. - The MEMLIMIT of the parent is inherited by the child, unless the INHESETMEMLIMIT flag in the inheritance structure is set on to indicate that the value specified in INHEMEMLIMIT is to be used to determine the child's MEMLIMIT. Another useful source of information is "z/OS UNIX System Services Planning". This FM says about MAXASSIZE: MAXASSIZE is the maximum region size (in bytes) for an address space that was created by rlogind, telnetd, and other daemons. The MAXASSIZE value limits the combined size of above and below the 16 M line storage. If MAXASSIZE is greater than LDALIMIT (the <16M limit), then the LDAELIM (the >16M limit) is set to MAXASSIZE - LDALIM. You can set a system-wide limit in BPXPRMxx and then set higher limits for individual processes. Use the RACF ADDUSER or ALTUSER command to specify the ASSIZEMAX limit on a per-process basis as follows: ALTUSER userid OMVS(ASSIZEMAX() This manual also has a couple of pages discussing all about limits. Of special interest to this discussion it the section called "How are limits handled after an identity change?", and the following sections. Its too much to copy&paste here. I suggets you have a read if your interested. (I've got the impression this part has not always be there in that detail. Great it is now) -- Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Region size for OMVS tasks
Trying to follow-up on the stuff that Peter has suggested, I'm still chasing that elusive '54M' - Who sets it? Where is it set? How can I override it? So, I created an IEFUSI that, whatever size is requested, whether it be below, above or MEMLIMIT, you get '0M'. Which, I agree, is probably a bit extreme, so I armed myself with an IDCAMS job in 'HOLD' on the input queue to do a DELETE xxx.LPALIB(IEFUSI), that I could release if things went pear-shaped. System had a certain amount of … umm … 'difficulty' in restarting, but JES itself started, so $AJ worked OK. But all the inits go to a 922 abend when they try to start. so the delete job never got a chance. Now I've got a system that won't IPL at all beyond a certain point. Have tried alternate members from SYS1.IPLPARM, but none of then specify sufficient paging space. Up the creek sans paddle, right now Sean On Tue, 20 Nov 2018 at 20:01, Peter Hunkeler wrote: > > Where did you get all this from? Is it documented somewhere, or is it > something you've 'soaked up through your fingertips' over the years? > > > So I went back to the FMs. For any question of kind "How does that UNIX > service behave regarding MVS resources, attributes, etc.", I always read > what the "z/OS UNIX System Services Programming - Assembler Callable > Services Reference" tells me. If something is to be said, there is a > section called "Usage Notes". Here are some interesting snippet: > > > For fork() it says: > > - The child process inherits the MEMLIMIT of the parent. > - The child address space inherits the following address space > attributes of the parent address space: region size and time limit. > > > For spawn() it says: > > - The region size of the parent is inherited by the child, unless the > INHESETREGIONSZ flag in the inheritance structure is set on to indicate > that the value specified in INHEREGIONSZ is to be used to determine the > child's region size. For more information, see What are soft limits? in > z/OS UNIX System Services Planning and Inheriting soft limits in z/OS > UNIX System Services Planning. > > - The MEMLIMIT of the parent is inherited by the child, unless the > INHESETMEMLIMIT flag in the inheritance structure is set on to indicate > that the value specified in INHEMEMLIMIT is to be used to determine the > child's MEMLIMIT. > > > Another useful source of information is "z/OS UNIX System Services > Planning". This FM says about MAXASSIZE: > > MAXASSIZE is the maximum region size (in bytes) for an address space > that was created by rlogind, telnetd, and other daemons. The MAXASSIZE > value limits the combined size of above and below the 16 M line storage. > If MAXASSIZE is greater than LDALIMIT (the <16M limit), then the LDAELIM > (the >16M limit) is set to MAXASSIZE - LDALIM. > > You can set a system-wide limit in BPXPRMxx and then set higher limits > for individual processes. Use the RACF ADDUSER or ALTUSER command to > specify the ASSIZEMAX limit on a per-process basis as follows: > ALTUSER userid OMVS(ASSIZEMAX() > > > This manual also has a couple of pages discussing all about limits. Of > special interest to this discussion it the section called "How are > limits handled after an identity change?", and the following sections. > Its too much to copy&paste here. I suggets you have a read if your > interested. (I've got the impression this part has not always be there > in that detail. Great it is now) > > > -- > > Peter Hunkeler > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Region size for OMVS tasks
If you have customized IEFUSI, reassemble you customized exit. IF not, copy SYS1.AOSB3 to SYS1.LLPALIB and re-ipl. -Original Message- From: IBM Mainframe Discussion List On Behalf Of Sean Gleann Sent: Wednesday, November 21, 2018 10:20 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Region size for OMVS tasks Trying to follow-up on the stuff that Peter has suggested, I'm still chasing that elusive '54M' - Who sets it? Where is it set? How can I override it? So, I created an IEFUSI that, whatever size is requested, whether it be below, above or MEMLIMIT, you get '0M'. Which, I agree, is probably a bit extreme, so I armed myself with an IDCAMS job in 'HOLD' on the input queue to do a DELETE xxx.LPALIB(IEFUSI), that I could release if things went pear-shaped. System had a certain amount of … umm … 'difficulty' in restarting, but JES itself started, so $AJ worked OK. But all the inits go to a 922 abend when they try to start. so the delete job never got a chance. Now I've got a system that won't IPL at all beyond a certain point. Have tried alternate members from SYS1.IPLPARM, but none of then specify sufficient paging space. Up the creek sans paddle, right now Sean On Tue, 20 Nov 2018 at 20:01, Peter Hunkeler wrote: > > Where did you get all this from? Is it documented somewhere, or is > > it > something you've 'soaked up through your fingertips' over the years? > > > So I went back to the FMs. For any question of kind "How does that > UNIX service behave regarding MVS resources, attributes, etc.", I > always read what the "z/OS UNIX System Services Programming - > Assembler Callable Services Reference" tells me. If something is to be > said, there is a section called "Usage Notes". Here are some interesting > snippet: > > > For fork() it says: > > - The child process inherits the MEMLIMIT of the parent. > - The child address space inherits the following address space > attributes of the parent address space: region size and time limit. > > > For spawn() it says: > > - The region size of the parent is inherited by the child, unless the > INHESETREGIONSZ flag in the inheritance structure is set on to > indicate that the value specified in INHEREGIONSZ is to be used to > determine the child's region size. For more information, see What are > soft limits? in z/OS UNIX System Services Planning and Inheriting soft > limits in z/OS UNIX System Services Planning. > > - The MEMLIMIT of the parent is inherited by the child, unless the > INHESETMEMLIMIT flag in the inheritance structure is set on to > indicate that the value specified in INHEMEMLIMIT is to be used to > determine the child's MEMLIMIT. > > > Another useful source of information is "z/OS UNIX System Services > Planning". This FM says about MAXASSIZE: > > MAXASSIZE is the maximum region size (in bytes) for an address space > that was created by rlogind, telnetd, and other daemons. The MAXASSIZE > value limits the combined size of above and below the 16 M line storage. > If MAXASSIZE is greater than LDALIMIT (the <16M limit), then the > LDAELIM (the >16M limit) is set to MAXASSIZE - LDALIM. > > You can set a system-wide limit in BPXPRMxx and then set higher limits > for individual processes. Use the RACF ADDUSER or ALTUSER command to > specify the ASSIZEMAX limit on a per-process basis as follows: > ALTUSER userid OMVS(ASSIZEMAX() > > > This manual also has a couple of pages discussing all about limits. Of > special interest to this discussion it the section called "How are > limits handled after an identity change?", and the following sections. > Its too much to copy&paste here. I suggets you have a read if your > interested. (I've got the impression this part has not always be there > in that detail. Great it is now) > > > -- > > Peter Hunkeler > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, send > email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ::DISCLAIMER:: -- The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. E-mail transmission i
Re: Region size for OMVS tasks
Thanks, Allan, but I can't get any tasks of any nature started - no VTAM, no TSO, so no copy is possible. (I'll squirrel that 'SYS1.AOSB3' info away, though, for possible future reference - hopefully never) Sean On Wed, 21 Nov 2018 at 16:38, Allan Staller wrote: > If you have customized IEFUSI, reassemble you customized exit. > IF not, copy SYS1.AOSB3 to SYS1.LLPALIB and re-ipl. > > -Original Message- > From: IBM Mainframe Discussion List On Behalf > Of Sean Gleann > Sent: Wednesday, November 21, 2018 10:20 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Region size for OMVS tasks > > Trying to follow-up on the stuff that Peter has suggested, I'm still > chasing that elusive '54M' - Who sets it? Where is it set? How can I > override it? > So, I created an IEFUSI that, whatever size is requested, whether it be > below, above or MEMLIMIT, you get '0M'. > Which, I agree, is probably a bit extreme, so I armed myself with an > IDCAMS job in 'HOLD' on the input queue to do a DELETE xxx.LPALIB(IEFUSI), > that I could release if things went pear-shaped. > System had a certain amount of … umm … 'difficulty' in restarting, but JES > itself started, so $AJ worked OK. > But all the inits go to a 922 abend when they try to start. so the delete > job never got a chance. > Now I've got a system that won't IPL at all beyond a certain point. > Have tried alternate members from SYS1.IPLPARM, but none of then specify > sufficient paging space. > > Up the creek sans paddle, right now > > Sean > > On Tue, 20 Nov 2018 at 20:01, Peter Hunkeler wrote: > > > > Where did you get all this from? Is it documented somewhere, or is > > > it > > something you've 'soaked up through your fingertips' over the years? > > > > > > So I went back to the FMs. For any question of kind "How does that > > UNIX service behave regarding MVS resources, attributes, etc.", I > > always read what the "z/OS UNIX System Services Programming - > > Assembler Callable Services Reference" tells me. If something is to be > > said, there is a section called "Usage Notes". Here are some interesting > snippet: > > > > > > For fork() it says: > > > > - The child process inherits the MEMLIMIT of the parent. > > - The child address space inherits the following address space > > attributes of the parent address space: region size and time limit. > > > > > > For spawn() it says: > > > > - The region size of the parent is inherited by the child, unless the > > INHESETREGIONSZ flag in the inheritance structure is set on to > > indicate that the value specified in INHEREGIONSZ is to be used to > > determine the child's region size. For more information, see What are > > soft limits? in z/OS UNIX System Services Planning and Inheriting soft > > limits in z/OS UNIX System Services Planning. > > > > - The MEMLIMIT of the parent is inherited by the child, unless the > > INHESETMEMLIMIT flag in the inheritance structure is set on to > > indicate that the value specified in INHEMEMLIMIT is to be used to > > determine the child's MEMLIMIT. > > > > > > Another useful source of information is "z/OS UNIX System Services > > Planning". This FM says about MAXASSIZE: > > > > MAXASSIZE is the maximum region size (in bytes) for an address space > > that was created by rlogind, telnetd, and other daemons. The MAXASSIZE > > value limits the combined size of above and below the 16 M line storage. > > If MAXASSIZE is greater than LDALIMIT (the <16M limit), then the > > LDAELIM (the >16M limit) is set to MAXASSIZE - LDALIM. > > > > You can set a system-wide limit in BPXPRMxx and then set higher limits > > for individual processes. Use the RACF ADDUSER or ALTUSER command to > > specify the ASSIZEMAX limit on a per-process basis as follows: > > ALTUSER userid OMVS(ASSIZEMAX() > > > > > > This manual also has a couple of pages discussing all about limits. Of > > special interest to this discussion it the section called "How are > > limits handled after an identity change?", and the following sections. > > Its too much to copy&paste here. I suggets you have a read if your > > interested. (I've got the impression this part has not always be there > > in that detail. Great it is now) > > > > > > -- > > > > Peter Hunkeler > > > > -- > > For IBM-MAIN subscribe / signoff
Re: Region size for OMVS tasks
if your using the PROG00 member to add the exit, deleting the member does nothing, you will probably need to issue a SETPROG EXIT DELETE,EXITNAME=xx too late now but remove this EXIT ADD if it exists maybe this will help Carmen Vitullo - Original Message - From: "Sean Gleann" To: IBM-MAIN@LISTSERV.UA.EDU Sent: Wednesday, November 21, 2018 10:56:00 AM Subject: Re: Region size for OMVS tasks Thanks, Allan, but I can't get any tasks of any nature started - no VTAM, no TSO, so no copy is possible. (I'll squirrel that 'SYS1.AOSB3' info away, though, for possible future reference - hopefully never) Sean On Wed, 21 Nov 2018 at 16:38, Allan Staller wrote: > If you have customized IEFUSI, reassemble you customized exit. > IF not, copy SYS1.AOSB3 to SYS1.LLPALIB and re-ipl. > > -Original Message- > From: IBM Mainframe Discussion List On Behalf > Of Sean Gleann > Sent: Wednesday, November 21, 2018 10:20 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Region size for OMVS tasks > > Trying to follow-up on the stuff that Peter has suggested, I'm still > chasing that elusive '54M' - Who sets it? Where is it set? How can I > override it? > So, I created an IEFUSI that, whatever size is requested, whether it be > below, above or MEMLIMIT, you get '0M'. > Which, I agree, is probably a bit extreme, so I armed myself with an > IDCAMS job in 'HOLD' on the input queue to do a DELETE xxx.LPALIB(IEFUSI), > that I could release if things went pear-shaped. > System had a certain amount of … umm … 'difficulty' in restarting, but JES > itself started, so $AJ worked OK. > But all the inits go to a 922 abend when they try to start. so the delete > job never got a chance. > Now I've got a system that won't IPL at all beyond a certain point. > Have tried alternate members from SYS1.IPLPARM, but none of then specify > sufficient paging space. > > Up the creek sans paddle, right now > > Sean > > On Tue, 20 Nov 2018 at 20:01, Peter Hunkeler wrote: > > > > Where did you get all this from? Is it documented somewhere, or is > > > it > > something you've 'soaked up through your fingertips' over the years? > > > > > > So I went back to the FMs. For any question of kind "How does that > > UNIX service behave regarding MVS resources, attributes, etc.", I > > always read what the "z/OS UNIX System Services Programming - > > Assembler Callable Services Reference" tells me. If something is to be > > said, there is a section called "Usage Notes". Here are some interesting > snippet: > > > > > > For fork() it says: > > > > - The child process inherits the MEMLIMIT of the parent. > > - The child address space inherits the following address space > > attributes of the parent address space: region size and time limit. > > > > > > For spawn() it says: > > > > - The region size of the parent is inherited by the child, unless the > > INHESETREGIONSZ flag in the inheritance structure is set on to > > indicate that the value specified in INHEREGIONSZ is to be used to > > determine the child's region size. For more information, see What are > > soft limits? in z/OS UNIX System Services Planning and Inheriting soft > > limits in z/OS UNIX System Services Planning. > > > > - The MEMLIMIT of the parent is inherited by the child, unless the > > INHESETMEMLIMIT flag in the inheritance structure is set on to > > indicate that the value specified in INHEMEMLIMIT is to be used to > > determine the child's MEMLIMIT. > > > > > > Another useful source of information is "z/OS UNIX System Services > > Planning". This FM says about MAXASSIZE: > > > > MAXASSIZE is the maximum region size (in bytes) for an address space > > that was created by rlogind, telnetd, and other daemons. The MAXASSIZE > > value limits the combined size of above and below the 16 M line storage. > > If MAXASSIZE is greater than LDALIMIT (the <16M limit), then the > > LDAELIM (the >16M limit) is set to MAXASSIZE - LDALIM. > > > > You can set a system-wide limit in BPXPRMxx and then set higher limits > > for individual processes. Use the RACF ADDUSER or ALTUSER command to > > specify the ASSIZEMAX limit on a per-process basis as follows: > > ALTUSER userid OMVS(ASSIZEMAX() > > > > > > This manual also has a couple of pages discussing all about limits. Of > > special interest to this discu
Re: Region size for OMVS tasks
I'm assuming that OP has no other functioning OS, no ability to edit or zap the failing system externally. I've never actually done this and don't have any example, but you might be able to use the IPL LOADPARM to force operator prompting at NIP. That lives in HMC on the IPL screen. If you could you respond 'properly' to the prompt, you might be able to nullify the poison exit. See https://www.ibm.com/support/knowledgecenter/en/SSB27H_6.2.0/fa2sc_r_ipload.html . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 323-715-0595 Mobile 626-543-6132 Office ⇐=== NEW robin...@sce.com -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Carmen Vitullo Sent: Wednesday, November 21, 2018 9:01 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):Re: Region size for OMVS tasks if your using the PROG00 member to add the exit, deleting the member does nothing, you will probably need to issue a SETPROG EXIT DELETE,EXITNAME=xx too late now but remove this EXIT ADD if it exists maybe this will help Carmen Vitullo - Original Message - From: "Sean Gleann" To: IBM-MAIN@LISTSERV.UA.EDU Sent: Wednesday, November 21, 2018 10:56:00 AM Subject: Re: Region size for OMVS tasks Thanks, Allan, but I can't get any tasks of any nature started - no VTAM, no TSO, so no copy is possible. (I'll squirrel that 'SYS1.AOSB3' info away, though, for possible future reference - hopefully never) Sean On Wed, 21 Nov 2018 at 16:38, Allan Staller wrote: > If you have customized IEFUSI, reassemble you customized exit. > IF not, copy SYS1.AOSB3 to SYS1.LLPALIB and re-ipl. > > -Original Message- > From: IBM Mainframe Discussion List On > Behalf Of Sean Gleann > Sent: Wednesday, November 21, 2018 10:20 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Region size for OMVS tasks > > Trying to follow-up on the stuff that Peter has suggested, I'm still > chasing that elusive '54M' - Who sets it? Where is it set? How can I > override it? > So, I created an IEFUSI that, whatever size is requested, whether it > be below, above or MEMLIMIT, you get '0M'. > Which, I agree, is probably a bit extreme, so I armed myself with an > IDCAMS job in 'HOLD' on the input queue to do a DELETE > xxx.LPALIB(IEFUSI), that I could release if things went pear-shaped. > System had a certain amount of … umm … 'difficulty' in restarting, but > JES itself started, so $AJ worked OK. > But all the inits go to a 922 abend when they try to start. so the > delete job never got a chance. > Now I've got a system that won't IPL at all beyond a certain point. > Have tried alternate members from SYS1.IPLPARM, but none of then > specify sufficient paging space. > > Up the creek sans paddle, right now > > Sean > > On Tue, 20 Nov 2018 at 20:01, Peter Hunkeler wrote: > > > > Where did you get all this from? Is it documented somewhere, or is > > > it > > something you've 'soaked up through your fingertips' over the years? > > > > > > So I went back to the FMs. For any question of kind "How does that > > UNIX service behave regarding MVS resources, attributes, etc.", I > > always read what the "z/OS UNIX System Services Programming - > > Assembler Callable Services Reference" tells me. If something is to > > be said, there is a section called "Usage Notes". Here are some > > interesting > snippet: > > > > > > For fork() it says: > > > > - The child process inherits the MEMLIMIT of the parent. > > - The child address space inherits the following address space > > attributes of the parent address space: region size and time limit. > > > > > > For spawn() it says: > > > > - The region size of the parent is inherited by the child, unless > > the INHESETREGIONSZ flag in the inheritance structure is set on to > > indicate that the value specified in INHEREGIONSZ is to be used to > > determine the child's region size. For more information, see What > > are soft limits? in z/OS UNIX System Services Planning and > > Inheriting soft limits in z/OS UNIX System Services Planning. > > > > - The MEMLIMIT of the parent is inherited by the child, unless the > > INHESETMEMLIMIT flag in the inheritance structure is set on to > > indicate that the value specified in INHEMEMLIMIT is to be used to > > determine the child's MEMLIMIT. > > > > > > Another useful source of information is "z/OS UNIX System Se
Re: Region size for OMVS tasks
This is what standalone restore is for, Sean. But if you don't have one built, you could try this: http://www.cbttape.org/~jjaeger/zzsa.html. I've used it before but not on anything more recent than a z10. If it will IPL, you can find your IEFUSI module and make it like IEFBR14. First Tennessee Bank Mainframe Technical Support -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN FIRST TENNESSEE Confidentiality notice: This e-mail message, including any attachments, may contain legally privileged and/or confidential information. If you are not the intended recipient(s), or the employee or agent responsible for delivery of this message to the intended recipient(s), you are hereby notified that any dissemination, distribution, or copying of this e-mail message is strictly prohibited. If you have received this message in error, please immediately notify the sender and delete this e-mail message from your computer. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Region size for OMVS tasks
Trying to follow-up on the stuff that Peter has suggested, I'm still chasing that elusive '54M' - Who sets it? Where is it set? How can I override it? It seems you missed this statement in my first reply in this thread: IEFUSI will gin control in the BPXAS address space before the UNIX process gets control. OMVS set REGION to the magic value 54M. This has not meaning and will later be replaced by the values from the originating batch job. (I don‘t know why 54M was chosen as the indicator value.) So, when your IEFUSI sees that value it should leave REGION and MEMLIMIT alone. Have tried alternate members from SYS1.IPLPARM, but none of then specify sufficient paging space. The 922 indicates that the initiator's ESTAE routine got control because of another ABEND, a program check, etc. I assume your IEFUSI code has a bug. It's not a question of paging space (Why do you think that is related to the problem?) Have you tried to deactivate the IEFUSI from the console? SETPROG EXIT,MODIFY,EXITNAME=SYS.IEFUSI,MODNAME=IEFUSI If you don't know EXITNAME and MODNAME, use D PROG,EXITS to get a list of active exits, then D PROG,EXIT,EXITNAME= to display MODNAME -- Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Region size for OMVS tasks
Just recognized that the parameter STATE=INACTIVE was missing in my previous post SETPROG EXIT,MODIFY,EXITNAME=SYS.IEFUSI,MODNAME=IEFUSI,STATE=INACTIVE -- Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Region size for OMVS tasks
Thanks to all that have responded - we're back and running again, but not due to any work on my part. My description of the failed system was not complete, for fear of confusing the issue - it is a guest z/OS under z/VM that is supplied by a.n. other party. I contacted them and the bad IEFUSI was renamed by a techie at their end. Rob: thanks for the referral to cbttape. I wasn't aware of that particular file there. I'll take a closer look later. I've had the comfort of a recovery system in the past. Sadly, that wasn't an option for me in this case. Peter: "...[54m value] has no meaning and will later be replaced..." Yes - Overnight I began to understand that. No matter what I've done so far, that SMF30RGN value continues to report '54M'. I 'new' thought for me in the course of this work is that SMF30RGN is the REGION size that was _requested_ (as per the documentation). It is not the size actually _given_ after IEFUSI/SMF/JES, etc have finished their meddling. As far as I make out, there is no such 'after the fact' value logged in any part of the type30 record (or any other). Which basically means that all this work has been a waste of time, based on a misconception. Peter again: [paging space related to the problem]... sorry - my poor description there. The alternate SYS1.IPLPARM(LOADxx) member leads to an incomplete definition that does not specify any paging space, so it won't IPL. Carmen and Peter: I simply did not think about the possibilities of SETPROG EXIT..., My mind was chasing itself in circles at the time. And then the supplier's technician fixed things up. I must re-visit my failed 'back-out' LOADPARM member and make sure it brings up a minimal system - possibly with whatever I find on the cbttape. And abandon this line of effort - I'm pretty certain that SMF30RGN point above is correct. Unfortunately, that leaves the cause of the original IEW4000I and CSV031I messages unsolved. I will have to think of a different way to attack the problem. Regards Sean On Wed, 21 Nov 2018 at 20:23, Peter Hunkeler wrote: > Just recognized that the parameter STATE=INACTIVE was missing in my > previous post > > SETPROG EXIT,MODIFY,EXITNAME=SYS.IEFUSI,MODNAME=IEFUSI,STATE=INACTIVE > > > -- > > Peter Hunkeler > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Region size for OMVS tasks
http://mzelden.com/mvsutil.html On Thu, Nov 22, 2018 at 2:43 AM Sean Gleann wrote: > > Thanks to all that have responded - we're back and running again, but not > due to any work on my part. > > > > My description of the failed system was not complete, for fear of confusing > the issue - it is a guest z/OS under z/VM that is supplied by a.n. other > party. I contacted them and the bad IEFUSI was renamed by a techie at their > end. > > > > Rob: thanks for the referral to cbttape. I wasn't aware of that particular > file there. I'll take a closer look later. I've had the comfort of a > recovery system in the past. Sadly, that wasn't an option for me in this > case. > > > > Peter: "...[54m value] has no meaning and will later be replaced..." Yes - > Overnight I began to understand that. > > No matter what I've done so far, that SMF30RGN value continues to report > '54M'. I 'new' thought for me in the course of this work is that SMF30RGN > is the REGION size that was _requested_ (as per the documentation). It is > not the size actually _given_ after IEFUSI/SMF/JES, etc have finished their > meddling. As far as I make out, there is no such 'after the fact' value > logged in any part of the type30 record (or any other). > > Which basically means that all this work has been a waste of time, based on > a misconception. > > > > Peter again: [paging space related to the problem]... sorry - my poor > description there. The alternate SYS1.IPLPARM(LOADxx) member leads to an > incomplete definition that does not specify any paging space, so it won't > IPL. > > > > Carmen and Peter: I simply did not think about the possibilities of SETPROG > EXIT..., My mind was chasing itself in circles at the time. And then the > supplier's technician fixed things up. > > > > > > I must re-visit my failed 'back-out' LOADPARM member and make sure it > brings up a minimal system - possibly with whatever I find on the cbttape. > > And abandon this line of effort - I'm pretty certain that SMF30RGN point > above is correct. > > > > Unfortunately, that leaves the cause of the original IEW4000I and CSV031I > messages unsolved. I will have to think of a different way to attack the > problem. > > > Regards > > Sean > > > On Wed, 21 Nov 2018 at 20:23, Peter Hunkeler wrote: > > > Just recognized that the parameter STATE=INACTIVE was missing in my > > previous post > > > > SETPROG EXIT,MODIFY,EXITNAME=SYS.IEFUSI,MODNAME=IEFUSI,STATE=INACTIVE > > > > > > -- > > > > Peter Hunkeler > > > > -- > > For IBM-MAIN subscribe / signoff / archive access instructions, > > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- 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...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Region size for OMVS tasks
Peter, Mike: Yes, I remember Peter pointing at Mark's page, but for some reason I moved on past that to some other line of enquiry. I've now done what you said, and the results from REXXSTOR in PuTTY are: V I R T U A LS T O R A G EU S A G E --- REGION REQUESTED: 55296K LIMIT IN-USE AVAIL BELOW 16M: 8168K 4K 8164K ABOVE 16M: 2088984K 840K 2088144K So, the 55296K is that 54M that I've been chasing and the rest of the report shows that I've been given the maximum amount of memory possible - 2G, right? So this whole exercise along with the temporary killing of my z/OS system *has* been a waste of time. I'm still left with the two messages though. And further work by one of the developers shows that the problem occurs only when BPX_SHAREAS=YES is defined. Setting BPX_SHAREAS=NO makes the memory problem go away, but run-time increases significantly. Thanks for all your support on this problem, Peter - and everyone else who added their thoughts, too. (I'm not letting this problem go though - this is one of those times when I start behaving like a terrier with a rat) Regards Sean On Thu, 22 Nov 2018 at 15:44, Peter Hunkeler wrote: > > > > >http://mzelden.com/mvsutil.html > > > > Yep, this is the invaluable link. As I wrote before, try the REXXSTOR rexx > found there and run it in a) TSO, b) TSO -> OMVS (shell under TSO), c) > putty (shell vie TCP/IP). If possible run in the environment where you‘re > getting the out of stroage, and run it under the userid that is getting the > problem. This may or may not give you a hint what to do next > > > — > Peter Hunkeler > > > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Region size for OMVS tasks
Peter, Mike: Yes, I remember Peter pointing at Mark's page, but for some reason I moved on past that to some other line of enquiry. I've now done what you said, and the results from REXXSTOR in PuTTY are: V I R T U A LS T O R A G EU S A G E --- REGION REQUESTED: 55296K LIMIT IN-USE AVAIL BELOW 16M: 8168K 4K 8164K ABOVE 16M: 2088984K 840K 2088144K So, the 55296K is that 54M that I've been chasing and the rest of the report shows that I've been given the maximum amount of memory possible - 2G, right? Have you cut some columns? There should be more. The "Limit" is a bit misleading, since you can only have some 1.5G, the rest is in use by the common area. Anyway, this session is not about to run out of storage, because only 840K are in use. But this is you session, not the developer's, who is having the problems, right. Can you have him to run that REXX after login and once he got to the out of storage? Since the problem occurs only with _BPX_SHAREAS=YES, when all the processes share a single address space, what exactly are they trying to do? What has change since it worked? -- Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
AW: Re: Region size for OMVS tasks
>Peter: I'm still trying to fully assimilate what you've said - very detailed & complete. Where did you get all this from? Is it documented somewhere, or is it something you've 'soaked up through your fingertips' over the years? I pasted one section which is one part of the „documented somewhere“. There is probably more parts that are documents, but I was too lazy to seek them all. So it‘s comes to „soaked up through your fingertips“, or better „discussing on fora“ and soaking up though the eyes :-) I‘ve been following and teaching z/OS UNIX for a couple of years when it came out in 1994. A lot has been discussed, and tested back then. That is why I wrote 2fading memory“. I haven‘t been following changes to z/OS UNIX as close as I used to. >Given that (probably poorly-informed) stance, then REGION and MEMLIMIT limits become pretty much meaningless. Don't they? I‘m can agree regarding REGION; I do not regarding MEMLIMIT. I‘m convinced a program going wild using 64bit memory can bring the system down in no time, if it is *not* limited to a reason amount. Remember: Even though a z13, or a z14 can have up to 10TiB, or 32TiB of real memory installed, z/OS V2.2, and V2.3 can only support up to 4TiB. 4TiB is nothing compared to 16EiB (the full 64bit addressing range). Storage finally needs to be backed by real storage. And, real storage needs to be backed by paging storage (virtual flash memory or paging DASD). Given the fact that the largest supported DASD EAV volume is 1TiB now, you would need 16.8 Million 1TiB paging devices to be able to back one single 64bit address space. From experience I know that programs *do* eventually go wild. Better protect your system with a low MEMLIMIT, and allow larges values only sparingly. My $0.02 only, of course. — Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
AW: Re: Region size for OMVS tasks
>http://mzelden.com/mvsutil.html Yep, this is the invaluable link. As I wrote before, try the REXXSTOR rexx found there and run it in a) TSO, b) TSO -> OMVS (shell under TSO), c) putty (shell vie TCP/IP). If possible run in the environment where you‘re getting the out of stroage, and run it under the userid that is getting the problem. This may or may not give you a hint what to do next — Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
AW: Re: Region size for OMVS tasks
One more thought: Look At he SMF30 records for one such session. You should get an idea of what‘s going on in that process and its child processes. There will be one record for each command, i.e. when a fork()ed or spawd()ed process ends, and at each exec(). You may find the one program eating up all that storage. — Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
