There's a huge difference in the complexity of the tables between 7.1 and 7.2. In 7.1 it was reasonable easy to fix the "customer has deleted the provisioning queue" problem by closing the audits.
In 7.2, such a delete provision job, should it exist, would need to close the open audits of tasks in the queue, set the state of links & approvals that are in pending state to OK or Failed, or atleast set mcChecklink to the current time and clear the and add/del/mod audit so its re-evaluted. And also most likely need to delete the PVOs that were in process, and the potentially grouped PVOs from both mxi_entry & mxi_values and fix the other related tables that could otherwise cause changes/approvals/assignments to fail or not process at all for the foreseable future. Most of the tables that needs to be patched are not writable by the runtime account so I'm not really seeing how a job can do this properly, atleast not for production environment use. This is not the description for how to create such a job, its all from memory and probably missing a few vital things 
We (Are, me & others in the team) have spent quite a lot of time on support-calls where the source of the problems were deletions of the provisioning queue that someone had decided must be a perfectly normal way of solving performance problems or accidental updates because the option was right there in the menu. We even shipped a job with the product that did the same as a template if I remember correctly with the intent for it to be used in development systems. Production was were it ended up usually. So this option had to go, and good riddance to it! :-)
