If it fails, you get an ABEND. Period. You either get the storage you requested or it ABENDs.
The only "overflow" that I am aware of is of SQA into CSA. And, IIRC, even if that happens, the subpool number is still the one for SQA (and ESQA similarly). -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * [email protected] * 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 Assembler List > [mailto:[email protected]] On Behalf Of Scott Ford > Sent: Thursday, June 07, 2012 7:49 AM > To: [email protected] > Subject: Re: Getmain question > > Peter, > > I am confused, can you help me understand. I read your your > excellent explanation. > If the Getmain fails...what's the result ? Abend ? or bad rc ? > > We specify Getmain Ru,lv=(1) > I understand it's unconditional, Checkzero= no ...no problem here > > Scott ford > www.identityforge.com > > On Jun 7, 2012, at 7:36 AM, Peter Relson <[email protected]> wrote: > > >> But Binyamin said that GETMAIN RU does not have a > >> defined return code; and that's not so. > > > > The only time GETMAIN RU can have a non-0 RC is when > CheckZeroRC=YES is > > specified. > > Thus, there is a *useful* return code for GETMAIN RU only when > > CheckZeroRC=YES. > > So GETMAIN RU has a "defined return code" of 0 but, as > Binyamin wrote, > > that is meaningless in this case since > > for this invocation the R15 is always 0 upon return (as it > abends if the > > obtain fails). > > > > SP229 never "spills" into SP230. If the trace shows SP230 > then there were > > obtains from SP230. > > If the trace does not show SP229 then there were no obtains > from SP229 > > within the timespan represented in the trace. > > > > AllowUserKeyCSA has nothing to do with obtains from non-CSA > subpools. > > There are no "issues" with the AllowUserKeyCSA parameter > other than with > > anyone who does allow it who cares about system integrity. > > > > Peter Relson > > z/OS Core Technology Design > >
