IEFBR14 - At begining or end of Job ? Which is better

tugga11 · New User Joined: 19 May 2009 Posts: 10 Location: Charlotte

HI

We have delete steps using IEFBR14 to delete temporarily used files in Jobs.
1. Does IEFBR14 take same time to delete Files on DASD as well as migrated files ?
2. Many Monthly jobs contain delete steps for Intermediate files created at the beginning of the job. This leads to files present in DASD unnecessarily till the next month’s run and also this results in increased elapsed time to due delays in RECALL. Can we have better elapsed time by placing IEFBR14 steps as the last step in Job ? We will definitly save on DASD if IEFBR14 is placed as last step in Job.

PLease let me know your thoughts on whether it ggod to have IEFBR14steps at the end of Job rather than at beginning , especially for Monthly Jobs

Escapa · Posted: Thu Sep 10, 2009 12:39 am

place won't matter in case of migrated dataset...whether you keep it at start or end.... it is gonna take its time it you try to delete or access..

Robert Sample · Posted: Thu Sep 10, 2009 12:41 am

1. IEFBR14 takes a small amount of time to run -- more if HSM is having to recall the data sets.
2. The answer is, as it so often is, ... it depends. For example, if the monthly jobs create files that could be needed during the month for reruns then they should only be deleted at the start of the next month. If they are nothing but temporary files, delete them at the end of the job. This tends to be an application-specific thing.

There is a product called CA-11 which handles this type of thing -- it will make sure files created during a job are not there; it can also be used to restart job processing should an abend occur part way through. I'm sure there's others as well but I'm most familiar with CA-11.

enrico-sorichetti · Posted: Thu Sep 10, 2009 12:46 am

there are two factors to take into account..
1) recall time
2) restart procedures...

for point 1 do not use iefbr14, use idcams delete, it will be trasformed into an hdel, so there will not be any recall time

for point 2 it' s better to have the cleanup job at the beginning,
if the restart policy is to submit from the beginning You will not have to write a cleanup job for restarts

tugga11 · New User Joined: 19 May 2009 Posts: 10 Location: Charlotte

Thanks for all your replies.

Terry Heinze · Posted: Thu Sep 10, 2009 7:48 am

One advantage of placing your IEFBR14 as the 1st step instead of the last is that you can rerun part of the job at any step without having to recreate needed input files, assuming of course that you don't need to "undo" any updating that has taken place. I also prefer IDCAMS over IEFBR14 for the reason enrico stated. Why restore to disk a file that you are about to delete anyway. Makes no sense and a waste of time. Also, I like to delete output files in the step immediately before they are created instead of at the beginning. Makes rerunning a portion of the job much easier. If your deletes are all in one step at the beginning, you have to selectively delete only the output files from the point of the rerun. Of course CA-11 does this for you automatically, so my method is good for "manual" deletions.

P.RAJESH · New User Joined: 20 Mar 2008 Posts: 54 Location: chennai

Hi Terry Heinze,

As in your post we are also replaced cleanup step at start of every job to placeing deletion files step before creation step.

By this we can save batch duration time ofcourse it is manual process.

MBabu · Posted: Thu Sep 10, 2009 9:51 am

Why can't you use the standard DISP=(MOD,DELETE,DELETE) first step and DISP=(NEW,DELETE,DELETE) in the main step? Do you need these 'temporary' data sets around all month? What am I missing here?

gcicchet · Posted: Thu Sep 10, 2009 10:19 am

Hi,

DISP=(MOD,DELETE,DELETE) will recall the dataset if it's migrated.

If you are going to use DISP=(NEW,DELETE,DELETE), what happens when the file is required in another step ?

If you are going to use DISP=(NEW,DELETE,DELETE), you might as well create true temporary files ie. DSN=&&TEMP

Gerry

MBabu · Posted: Thu Sep 10, 2009 12:00 pm

The point is, why are these data sets being left around at all? Why not be sure they are gone at the start of the job and delete them at the end?

I have seen jobs that need temporary data sets that are cataloged for the life of a job so that other server address spaces can find and read or write them (I had one of those just 2 weeks ago), but even for a cataloged data set, if you force delete it at the start of the job, allocate it when needed and delete it at the end of the job, the whole problem seems to go away. Using a temporary cataloged data set between address spaces is very rare so a real temp data set seems sufficient here. Thats why I think I'm missing something.

expat · Posted: Thu Sep 10, 2009 12:10 pm

Terry Heinze · Posted: Thu Sep 10, 2009 6:28 pm

MBabu · Posted: Fri Sep 11, 2009 9:37 am

Expat & Terry - yes - that is what I was missing - thanks