That is what you want for two runs on Day 7 and Day 8.
However, immediately after running the job, you have lost your input data.
Try it. Pretend you are at the start of day 7. Run the job. Run it again. Now what day is it?
To make the job re-runnable, you have to back-up the dataset before running the job, and you need a restore for when you are doing a re-run.
If you want to run the risk of accidental submission/selecting the wrong file for a re-run, I don't see why you are worried about an abend in the step. It is a one-record file, what do you think can go wrong with it? Space problem? S0C7?
OK, yes you can have the job fail. My point is not that you can't, but if you are worred about that why are you not more worried about destroying your input file? Much more likely to be problematic than the unaided chance of a failure in the job.
Joined: 22 Apr 2006 Posts: 6258 Location: Mumbai, India
I, too, don't advocate using same file as input and output; but then just yesterday one of the other co-worker was beating around the same bush (-sh*t) and I said use (OLD,KEEP,KEEP) for SORTOUT in the hope of not loosing the DSN but then it was a very poor suggestion.
If I remember correctly, DFSORT does NOT support the use of the same data set for SORTIN and SORTOUT for a COPY operation, which is what your SORT application is doing. For a COPY operation, DFSORT opens the SORTIN and SORTOUT data sets in parallel. It reads a record from the data set and then writes that record to the same data set. Obviously, this can result in messing up the data set. It may work sometimes, but it is NOT guaranteed to work. You're plotting a time-bomb, when time it not right - it gets risky.
By the way, your SORT statements are not correct, you don't need the red text ZD:
I've never heard of any "control file" that is just bodged-about with a sort or any other utility. For any type of run-control file, you need a connection to the previous day, and you need a business date. You need control information updated when the schedule is "cut", and you need to verify that the whole lot hangs together logically - meaning also that the program maintaining the control file has to know about working days and holidays, as they apply to your system.
If you are looking for a conceptual shift to make this work, just call it a NOCONTROL file. It'll avoid any false sense of security, and you can mess around with it as you like.
I imagine you'll change your COPY so that it will do an actual sort, just bodge your way past that one. Remind the OPS in the run instructions to "NUMBER OFF" when they have to edit the dataset. Wouldn't that be fun?
For a copy application, the SORTIN data set should not be the same as the SORTOUT data set or any OUTFIL data set because this can cause lost or incorrect data or unpredictable results.
For a sort application, the SORTIN data set should not be the same as any SORTWKdd data set because this can cause lost or incorrect data or unpredictable results. The SORTIN data set can be the same as the SORTOUT data set or an OUTFIL data set, but this situation can lead to the loss of the data set if the sort application does not end successfully.
So you should NOT use the same input and output data set for a COPY application.
You can use the same input and output data set for a SORT application, but it's usually NOT a good idea.