This can be difficult and the details of what the data is and how it was killed are very important.

You may be able to accomplish what you need via ^ZJRNFILT as Dmitry mentioned.  But that requires you to find where the KILL is in the journal files, and determine how to filter out the KILL without filtering other updates that are required.  Commonly this requires replaying ALL journals from the time of the event forward, to avoid stale data replacing current data. So the longer you wait, the more journals you have to replay.

If the global contains information that has not changed in a long time, then that stable data is probably not in the journal files anymore.  You would need to restore from a backup in that case.


Eric, your best bet is to investigate at operating-system level; a dead job means it's no longer around as far as can be detected within Ensemble.  As to what to check, this depends very much on the specific OS platform you're running; different ones have different tools.

For Linux, try looking in /var/log/messages.  For Windows, the Event Viewer is where to go.  And there may be useful information in the Caché cconsole.log.  

The WRC can help you with getting to the bottom of problems like these because there are many reasons why a job might die unexpectedly.


Quoting Robert

But I'm already working on suggestion #2.

Much better approach! I think you'll be much more successful that way.  Erik

Eric, consider contacting the InterSystems WRC if you have not found and resolved the issue so a support advisor can help you.