No! See John Eells' post below. The HDELETE functionalty was added to
allocation and is triggered by the recognition of IEFBR14.
So, IEFBR14 has not increased in size but the addittional functionality within
allocation may well be the culprit.
> Date: Wed, 4 Aug 2010 15:58:04 +0100
> From: martin_pac...@uk.ibm.com
> Subject: Re: Question on size of IEFBR14 and z/OS V1.11
> To: IBM-MAIN@bama.ua.edu
>
> Are we missing something here? Didn't R.11 allow IEFBR14 to issue HDELETEs
> as appropriate? And mightn't that take up some 24-Bit virtual?
>
> (In addition to everything others are saying about fragmentation.)
>
> Cheers, 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
>
>
> 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
>
>
______________________________________________________________________
> Date: Wed, 4 Aug 2010 08:15:54 -0400
> From: ee...@us.ibm.com
> Subject: Re: Question on size of IEFBR14 and z/OS V1.11
> To: IBM-MAIN@bama.ua.edu
>
> <snippage>
>
> IEFBR14 itself has no larger a storage footprint than it had in z/OS R9
> (or, indeed, than it has had since we added SR 15,15 to it many many
> moons ago). It's Allocation processing that was changed to recognize
> IEFBR14 as a special case when you tell it to. I smell a possible
> storage fragmentation problem inflicted by one or more of the preceding
> steps.
>
> --
> John Eells
> z/OS Technical Marketing
> IBM Poughkeepsie
> ee...@us.ibm.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
