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
