IDCAMS would be another one. (That was my reaction when I first heard of 
this.) But note both of these are MUCH harder because that would require 
reading of SYSIN - perhaps from data sets.

Martin

Martin Packer
Performance Consultant
IBM United Kingdom Ltd
+44-20-8832-5167
+44-7802-245-584

email: [email protected]

Twitter ID: MartinPacker

"They're figuring out that collaboration isn't a productivity hit, it 
makes them smarter." Sam Palmisano on BlogCentral, 26 November 2008



From:
"Chase, John" <[email protected]>
To:
[email protected]
Date:
07/06/2009 20:50
Subject:
Re: IEFBR14 (was: EXEC Above the Bar)
Sent by:
IBM Mainframe Discussion List <[email protected]>



> -----Original Message-----
> From: IBM Mainframe Discussion List On Behalf Of Paul Gilmartin
> 
> On Sun, 7 Jun 2009 15:05:57 -0400, Jim Mulder wrote:
> >
> >  The enhancement in z/OS 1.11 is that Batch Allocation/Unallocation
> >processing is checking to see if the program name is exactly
'IEFBR14',
> >and if so, for migrated data sets whose DISP is DELETE, it simply
> >HDELETEs them without HRECALLing them.
> >
> I stand corrected.  Thanks.
> 
> So this makes IEFBR14 a sort of reserved word.  What happens if a
> programmer writes his own program named IEFBR14 which actually
> opens the data set?  A new form of Sx13 ABEND?  Does the enhancement
> check whether IEFBR14 is loaded from a STEPLIB?
> 
> Now that IEFBR14 will be handled specially, will the enhancement
> skip executing it?  One contributor to these lists suggested a few
> months ago that the initiator should detect IEFBR14 and skip
> execution to avoid some overhead.  There was a consensus that the
> test might introduce more overhead than it saves, and also
> introduce other unexpected behavior.
> 
> Is there similar assistance for other environments?  It has been
> suggested that for Unix System Services or IRXJCL the programmer
> use BPXWDYN( ALLOC DELETE ); BPXWDYN( FREE ); but this results
> in HRECALL.
> 
> The design meetings must have been interesting.

Similar functionality might be handy in ADRDSSU wrt migrated datasets to
be deleted:

//STEP1  EXEC PGM=ADRDSSU[,parms]
//OUTDD   DD  DUMMY
//<other required DD statements>
//SYSIN   DD  *
  DUMP DS(. . .) -
  PURGE         -
  . . .

I.e., if function = logical DUMP with PURGE, *AND* the output is DUMMY,
then just HDELETE any included datasets that are migrated at the time
rather than HRECALL them just to write them to the bit bucket.

Or does he already do that?

    -jc-

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html







Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU






----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Reply via email to