Kill Zombie Jobs: Add functionality to be able to recover from a corrupted Jobtable on an FTA

When an FTA crashes and gets a corrupted Jobtable and the Jobtable must be removed, jobs that were in EXEC status before the crash remain in EXEC state and take run slots against the server limit, and job stream limit if applicable, even after the jobs are cancelled. There is no way to release the run slot, and the limits need to be raised to accommodate the zombie jobs. This leads to the server limit being higher than desired in the next plan.

There are a couple ways I could see to add functionality that would allow for recovery from a corrupted Jobtable on an FTA:

1: add a new status of "UNKNOWN" that the FTA can set the jobs to after it discovers that the jobs are in EXEC but have no record in the Jobtable. This UNKNOWN status should function similarly to ABEND wherin the job could be rerun, cancelled, or confirmed, but should not trigger automatic abend recovery options. Jobs in UNKNOWN should hold a run slot until the job is rerun, cancelled, or confirmed.

2: add a user interface option to move the job internal status out of EXEC. This could be a command line tool on the master or FTA that sends the same message that would have been sent by the FTA on which the job runs upon completion of the process. In essence it would be like "conman confirm" but forcing the internal status out of EXEC, not putting the job into SUCCP or ABENP. Perhaps it could be implemented with "conman confirm [jobselect];{succ | abend};forced"? A similar functionality could be also added to the DWC.

While "confirm ... ;forced" seems like it might be easier to implement, it could also be inappropriately applied to jobs that are not zombie jobs and would break the ability to kill the underlying process in that misuse case. The UNKNOWN status more directly fits as a solution to actual issue of zombie jobs.