For IEFBR14 two things:
#1. I constantly use; DISP=(MOD,DELETE), so if the data set exists; it will be
allocated and then deleted, but if the data set does not exist; it will be
created and then deleted. I use SPACE=(TRK,(0)) in the IEFBR14 step for a data
set that I will later define with DISP=(NEW,CATLG). Now depending on the
setting in SYS1.PARMLIB(ALLOCxx) the data set may or may not be recalled before
deletion, see my #2 here for why.
#2. Starting with z/OS 1.xx (sorry can't remember which one, but it is there
for z/OS 1.13 and was in there for z/OS 1.12), in SYS1.PARMLIB(ALLOCxx) there
is a new setting:
From the z/OS 1.13 Init & Tuning Reference:
SYSTEM
Specifies the system defaults.
IEFBR14_DELMIGDS(LEGACY|NORECALL)
Specifies the policy on whether to recall a migrated data set
when you use an IEFBR14 JCL program with DD DISP=(x,DELETE) to delete the
data set. The recall is, in most cases, unnecessary, as the
data set is
being deleted anyway.
LEGACY
Indicates that the system is to recall HSM-migrated
data sets before deletion.
NORECALL
Indicates that the system can delete (through HSM
HDELETE processing) the data set without first recalling the
data set to the primary storage.
Default: LEGACY
So if in ALLOCxx you turn "NORECALL" on, then when using IEFBR14 in your JCL,
the data set will NOT be recalled, but an HDEL will generated instead and you
job will not wait.
Al Nims
Systems Admin/Programmer 3
Information Technology
University of Florida
(352) 273-1298
-----Original Message-----
From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf
Of Paul Gilmartin
Sent: Thursday, February 20, 2014 9:05 PM
To: [email protected]
Subject: Deleting multiple data sets
Often, after finishing a series of tests, I have several dozen data sets to
delete. Actually, I'm careless; often I don't delete them until the next time
I want to run similar tests, by which time most are migrated.
Over the years, I've used several techniques:
o Use TSO DELETE in an IKJEFT* step, possibly in an EXEC.
o IEFBR14 with DISP=(OLD,DELETE) Does this JCL error if DSN
doesn't exist? If I use DISP=(MOD,DELETE) will it allocate the
data set that will never be used? I understand that JCL now
bypasses recall if the data set is migrated. Good. I understand
that job step allocation now proceeds in parallel rather than
sequentially. Better, but does this apply to the IEFBR14 special
delete processing? (2.1 only? We're not there yet.)
o Type D in front of each on a DSLIST menu. Slow. I'm told that
our mostly non-sysplex configuration precludes some catalog
optimization that most programmers can rely on. And I must
remember to omit the .DATA and .INDEX members or I come back
from my coffee break and find my terminal hanging on a prompt.
Pity: DSLIST processing seems to operate sequentially. I wish
that when I type I in front of several data sets it would recall
the others while I'm viewing one.
o IDCAMS DELETE. This seems to be ignorant of migrate optimization.
Pity; IDCAMS DELETE is so close to TSO DELETE that that
optimization should be performed in common code.
You've probably guessed I'm impatient; when I do get around to cleaning up, I
want it to be over so I can start my tests.
What fits my skill set best would be a UNIX script that does:
while DSN in ..., do ( _BPX_SHAREAS=NO some-rexx-exec address TSO 'DELETE'
DSN ) & done
... I might need to pace it lest I exceed PROC_MAX. Too bizarre?
Anything else wrong with it? Would I gain nothing because of catalog
single-threading? Any other ideas?
Thanks,
gil
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions, send email to
[email protected] with the message: INFO IBM-MAIN
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
