Yossi, I'm not familiar with CommVault and the VMTools (although the VMs I use here do have them installed).  I have seen a variety of troubles cured by making sure the VMTools are up-to-date.  VMWare or CommVault support might be best for that. 

As for Caché, make sure that EnableVSSBackup is set to 1 (true) in your CPF and that SYS.VSSWriter.1 is running (check the process list in the Portal).  The VSS writer for Caché can be started only by an administrator on Windows.

I don't have much more advice, if this doesn't get you working, I would contact WRC directly.

Others, including me, were noting this message in the log you posted

02/08/21-09:17:54:464 (7016) 3 [Utility.Event] Error: Invalid Community Edition license, may have exceeded core limit. - Shutting down the system : $zu(56,2)= 0

which is definitely unhappy about the core count.  Rich has good advice if you are able to start the instance but are unable to run only some jobs.   If you have a full license and you are still unable to sort this out, reach out to the WRC and an advisor can assist.

Please let us know if you have progress, several of us are interested in your success.

Erik

Priya, there is a limit of eight CPU cores for the Community Edition of InterSystems IRIS products.  If you are using a Docker image, add

--cpuset-cpus=0-7
to your 'docker run' command.  On a native server, or VM, you need to limit the cores available using the methods for that server (or use one with fewer cores).

https://docs.intersystems.com/irislatest/csp/docbook/Doc.View.cls?KEY=AC...

Let us know if this resolves your trouble, and all best in migrating to IRIS.

Erik

Paras, On OpenVMS, versioning is handled by RMS services; the versioning is supported by the filesystem.  That versioning doesn't exist on Linux.  In %Library.File these might help (or might help Hans-Peter, too):

GetFileDateCreated() -> gives creation date to the second in $H format, given the filename.

GetFileDateModified() -> last-modified time in $H format, again given the name.

And the FileSet query might help browsing the directory, too:

query FileSet(directory As %String(MAXLEN=""), wildcards As %String, sortby As %String = "", includedirs As %Boolean = 0, delimiter As %String = ";")
 

Paras, I think understanding more about the specific conditions you are working with would help.  Is the encryption supported by the printer itself, or are there intermediary agents that would receive text from IRIS, encrypt, send, decrypt, and feed the printer?  How does printing to this printer work now outside of IRIS?  And knowing details like OS, and printer model helps too.  The choice of page-description language and printer driver can be important too.

Erik

Since you are working on Windows, review the advice here: https://community.intersystems.com/post/using-intersystems-iris-containers-docker-windows

If you are seriously stuck, you might consider contacting the WRC for help.  Understanding the context and your overall goal can be important in solving troubles like this -- and also preventing other troubles that you might encounter.

Erik

Muni,

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.

Erik

You can get good performance on any platform.  The real keys to performance are how you specify and configure the hardware and software for the kind of workload you will run.  I share Robert Cemper's preference for Linux or UNIX, but a good Windows administrator can make a Windows server run very well.

Have you been in contact with your InterSystems account team?  They can be a good source of information in the context of what your application needs are.

Erik

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.

Erik