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

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

Robert, although we only support containers on Linux, we have some information concerning Docker for Windows since many people find themselves in just this situation.

https://community.intersystems.com/post/using-intersystems-iris-containers-docker-windows
 

For your Durable %SYS directory, try a named volume instead of a bind mount (use docker volume create ...).  

Thanks for your post and for all your contributions in the DC.   Erik

Sylvie, you didn't specify the exact version you are using; in v2016.1.1 and later, the limit of 999 journal files per day was removed.

If you are creating a lot of journal activity, and the 999 limit applies to you, you can also increase the size of each journal file so fewer are created each day.  As Eduard posted, testing your workload is the way to determine the journal space you need.

Farhan,

It's certainly possible to create a user-defined audit event and add audit events from your application code.  What's the purpose of tracking patient IDs?

Audit events are stored in the CACHEAUDIT database and by default are purged after a set number of days. So using the audit log to track patient IDs might not be the right solution.  It all depends on what your ultimate goal for tracking is.  

You might want to contact the WRC or your account team for more-specific help.

Erik

HP-UX uses initscripts to start processes. So you need an initscript which includes commands to start, stop, and check status of processes.

Let's take the Arbiter; it's a standalone process at OS level and is easier:

The Arbiter is an instance of ISCAgent, whose initscript is likely at /sbin/init.d/ISCAgent on your HP-UX system.

Symlink to that script in the runlevel directory for the runlevels you need this to run; this should be /sbin/rc3.d for runlevel 3 or /sbin/rc4.d for runlevel 4. You can review the HP-UX runlevels by reading the manpage for init (1M) (the command man init should get you there).

In those directories, you'll see names starting with S##name and K##name (digits for the #). This signals which services are (S)tarted or (K)illed when the system switches to this runlevel. On my test machine here, in /sbin/rc3.d I see S900ISCAgent, and I can see that it would start after

S870hpsmhd.

You would need a similar initscript which would start Cache'. I would expect that the Arbiter would be run on a host distinct from its mirror members. You can review the ISCAgent initscript to get a sense of how these are organized.