Add a timeout to the MIGRATE STGPOOL command

Every day, we encounter migration processes that are waiting for access to an input file that is busy. Examples of waiting processes (stgpool FER.FILE is devclass=FILE):

63 Migration Volume /sppool/fer3/003CFCB3.BFS (storage pool FER.FILE), Moved Files: 0, Moved Bytes: 0 bytes, Deduplicated Bytes: 0 bytes, Unreadable Files: 0, Unreadable Bytes: 0 bytes. Current Physical File (bytes): 48,122 KB Waiting for access to input volume /sppool/fer3/003CFCB3.BFS (158549 seconds). Current output volume(s): L86176L8.

64 Migration Volume /sppool/fer4/003CFC4B.BFS (storage pool FER.FILE), Moved Files: 430, Moved Bytes: 3,023 GB, Deduplicated Bytes: 0 bytes, Unreadable Files: 0, Unreadable Bytes: 0 bytes. Current Physical File (bytes): 17,084 KB Waiting for access to input volume /sppool/fer4/003CFC4B.BFS (148155 seconds). Current output volume(s): L86187L8. 

If left alone, the processes above will prevent subsequent MIGRATE STGPOOL commands from running. I know the IBM philosophy is that migrations should run only when backups have finished, but in large environments, that is difficult to achieve. We have backups and migrations running all the time. These things would help us:

1) Add something like MAXRUNTIME to the MIGRATE STGPOOL command so that the processes die after a defined amount of time.
2) Have MIGRATE STGPOOL migrate only files that are both full and closed first.
3) Migrate filling volumes only after full volumes are done.

Thank you for your consideration.