I have this situation in CA7. JOBA runs at 00:01. JOBB is dataset triggered approximately at 9:00 (could be at a later time) and has JOBA as requirement, since the last time. These jobs run everyday and everything is fine, UNTIL a second file is received and JOBB is triggered again. This second file is not received very often. The second JOBB will wait in the REQ Queue until another JOBA runs. We need this second JOBB to execute when the second file is received. The file is sent by a client so it is always the same schid. If the file had different schids then I would know what to do but we cannot ask the client to do that.
I have thought of creating a batch job that will be dsn triggered by the same file and pull JOBB from the REQ Queue, if any. If JOBB is in the ACT or RDY queue then no job will be pulled. There will be a WAIT step of a minute or so to make sure the first JOBB starts executing and then the same batch job will create a POST statement to post JOBB. When a second file is received, the batch job will run and this time it will find JOBB in the REQ queue and will post it. If I use this batch job and if for any reason JOBA is delayed too many hours and runs after 9am then we run into the possibility of releasing the first JOBB ahead of time.
Is there another way to post the second JOBB? The file may arrive at any time.
If possible, have JOBB dependent on a data set that JOBA creates (can add a step to JOBA to do a D=data.set.name from U7SVC and data.set.name defined as a data set in CA 7 and as a requirement for JOBB). Job requirements required what I call job 'sequencing'--e.g., JOBA runs then JOBB then JOBA then JOBB, ad infinitum. Data set requirements that have a non-zero LEADTM do not require 'sequencing' (however 98 hours is the max 'look back' time for data set requirements).
Would that work even if JOBA runs only once and JOBB could be dsn triggered twice at very different times?
Yes, Saul, A dsn requirement will be automatically posted if it is created within the LEADTM entered on the DB.3.1 screen (as long as it is non-zero and not 99) no matter how many times the dependent job has run (no 'sequencing' required).