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=xxxxxx too late now but remove this EXIT ADD if it exists maybe this will help
Carmen Vitullo ----- Original Message ----- From: "Sean Gleann" <sean.gle...@gmail.com> 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 <allan.stal...@hcl.com> 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 <IBM-MAIN@LISTSERV.UA.EDU> 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 $AJnnnn 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 <p...@gmx.ch> 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(nnnn) > > > > > > 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 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 ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
