IBM Mainframe Forum

Hello,

I suspect that holding everything and manually releasing over 100 jobs a day would not be acceptable. . .

Hi -

I think I have the same issue. Let me try to provide an example:

1. Sending system transfers a file to us (stored as GDG) "FOO.BAR.FILE(+1)" - - - FOO.BAR.FILE.G0001V00
2. Sending system then sends the actual trigger to process the job
3. Sending system then sends a second file to us - stored as FOO.BAR.FILE.G0002V00
4. Job triggered by step 2 starts - picks up current generation (now FOO.BAR.FILE.G0002V00)
5. Sending system sends trigger to process job
6. Job triggered by step 5 starts (after completion of job in step 4) - picks up FOO.BAR.FILE.G0002V00 as the current generation (thus processing same file twice)

Note that there is a possibility that steps 4 and 5 are reversed - regardless the effect is the same - generation 1 is never processed, and generation 2 is processed twice.

The issue is that we have two asynchronous processes here. The creation of the GDG is not connected with the job trigger. I am hoping that someone has some suggestion for tying these two together.

Inserting a WAIT in the jobs would only make the situation worse - more files could be cataloged prior to the jobs actually running.

Any suggestions would be welcomed.

Your example makes no sense -- why would the SENDING system be issuing a trigger when the RECEIVING system should be the run running CA-7 and doing a data set trigger?

CA-7 allows you to specify POST ON CLOSE so as soon as the data set is closed CA-7 can submit a job. If this is not enough to remove your problem, you could specify DISP=OLD on the GDG base in the triggered job and then have an IDCAMS step delete all generations -- so there should never be more than one in the system at a time.

If the files are being created as fast as you say, you may have to start with a system redesign from the sending system on to create a process that won't allow files to be lost.

Hi Robert -

Thanks for the fast reply. Our facility frequently uses a two step method for file transfers and triggers. Step 1 is obviously the transfer itself. Step 2 actually runs U7SVC with something like "PARM='D=FOO.BAR.FILE.G0000V00'".

I am unfamiliar with POST ON CLOSE, but will give it a look. I believe we are already using DISP=OLD in the triggered job.

Thanks... Dwight