HDEL in front of each dataset name, instead of D.
Type HDEL on the first one, = on the rest.

On Thu, Feb 20, 2014 at 8:05 PM, Paul Gilmartin <paulgboul...@aim.com> wrote:
> 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN



-- 
Mike A Schwab, Springfield IL USA
Where do Forest Rangers go to get away from it all?

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Reply via email to