|
View previous topic :: View next topic
|
| Author |
Message |
David Zeigler
New User
Joined: 01 Feb 2007
Posts: 1
Location: Greenville,SC
|
|
|
|
Is there a way to get allocation not to generate a DFHSM recall for a dataset which is going to be deleted by IEFBR14 through a DD statement? These datasets may or may not exist at the time the IEFBR14 runs and therefore have the following disposition parameter (MOD,DELETE,DELETE).
They also may or may not be migrated by DFHSM to ML2. In the case where
they are migratied, allocation recalls the dataset before it is deleted
causing delays in the job run time waiting for the recall. |
|
| Back to top |
|
 |
cpuhawg
Active User
Joined: 14 Jun 2006
Posts: 331
Location: Jacksonville, FL
|
|
|
|
You could used the following step in front of the IEFBR14.
| Code: |
//HDEL001 EXEC PGM=IKJEFT01,
// PARM=' HDELETE ''HLQ.DATASET.HERE'' WAIT PURGE'
//SYSTSPRT DD SYSOUT=*
//SYSTSIN DD DUMMY
|
This JCL will perform a migration delete (if the file is migrated) and wait on it to be deleted. You can READ about the HDELETE command by entering TSO HELP HDELETE on the command line. |
|
| Back to top |
|
|
TizMe
New User
Joined: 05 Jan 2006
Posts: 72
|
|
|
|
I code my jobs like this.
It will allways return CC=0 and will not rquire a HSM RECALL.
| Code: |
//STEP000 EXEC PGM=IDCAMS
//SYSIN DD *
DELETE dataset.number.one
DELETE dataset.number.two
DELETE dataset.number.three
SET MAXCC=0
/*
//SYSPRINT DD SYSOUT=*
//*
|
|
|
| Back to top |
|
|
dick scherrer
Moderator Emeritus
Joined: 23 Nov 2006
Posts: 19244
Location: Inside the Matrix
|
|
|
|
Hello,
If the job gets to the dataset allocate in the br14, it is already too late - so deleting migrated datasets via br14 is not usually a good choice.
If you are only running the br14 to do some one-time housekeeping, you can also delete the file(s) in tso with no reacll.
If this is a regular job and you need to do this delete each run, the previous suggestions should work well for you. |
|
| Back to top |
|
|
|
|
