Does the generator lock the file? You could check to see if the file is locked.

If you can, have the software package create the file in one directory, and rename it into the final directory when its done. Since rename is atomic, the file will be complete as soon as it appears in the final directory. The background process can even ask the system to notify it when the directory changes so that it can respond faster than once every 10 minutes.

How do you define "open" and "closed"? You may want to have the software package write a well defined trailer at the end of the file right before it completes. That way, there is no ambiguity of whether the software is done.

If you have no control over the software package itself or the format of the file, one idea is to get some statistic about the file (last line or byte size), sleep, get the same statistic again and compare it to the last one. Loop that until the statistic didn't change. The problem with this is it is not certain to work unless you can guarantee that the software package writes more often than your script wakes up.

Edit: I like ikegami's solution better.

There are packages that do job scheduling, including handling dependencies between jobs and recovery from failures. You might investigate some of them.

A fundamental issue is whether you want the various jobs to be aware of each other, or whether you want the dependencies and coordination to be handled externally, as a job scheduler does.

I would try to avoid polling. It is inefficient and/or introduces latency. If you don't want the package that builds the file to initiate the subsequent jobs when it is done, you might consider having the package that starts that package do so synchronously and run the following jobs when the first one exits.

To determine whether some other process has the file open, I would try to open the file and set an exclusive lock on it. If any other process has it open, the attempt to obtain an exclusive lock will fail. If the other process has an exclusive lock, you might not even be able to open the file.

You say "other jobs". Depending on how they interact, you may have to be careful to avoid deadlock, where every job is waiting on some resource held by some other job and nothing can progress. If each job uses (locks for exclusive access) only one resource at a time, this won't be a problem.