· Aug 31, 2022

Using JOB to run a process in the background


I need to run some clean up routine in the background so loss of my terminal session won't stop the process.

I found the JOB command in the documentation.
JOB | ObjectScript Reference | InterSystems IRIS Data Platform 2022.1

When I try it, it doesn't seem to be doing much. I also expected this to become visible in the Background Tasks but that doesn't happen either.

Probably I am missing something.

This is the command I am running:
JOB ##class(HIHLib.Support.GetHL7MessageStat).ISBListingQuery("2017-01-01","2017-02-01",0,"WAHISCL",-1,0)::10

The same command without the ::10 has the same effect.

We are running on IRIS 2020.1.1.408.0

Discussion (5)0
Log in or sign up to continue

There's a distinction between Background Jobs and Background Tasks.

Backgound job is anything you run using JOB command. Background Task is a limited set of named actions (AuditCopy, AuditExport, AuditPurge, Backup, CompactDBSpace, CopyNamespaceMappings, CreateDatabase, Compile, DatabaseIntegrityCheck, DataMigration, DefragmentDB, Delete, EnableEnsNamespace, Export, ExternalLangServers, FileMan, Import, SQLExport, SQLImport, SQLExportStatement, SQLImportStatement, QueryExport, JournalIntegrityCheck, LinkTable, LinkProcedure, MirrorActivateCatchupDB, MirrorRemoveDB, MirrorMountDB, MirrorAddDatabases, ModifyDatabaseSize, RebuildIndices, TuneTable, TuneTables, PurgeAllCachedQueries, JobShowPlan, JobSaveQuery, JobPossiblePlans, JobComparePlans, ShardActivate, ShardAssign, ShardVerify, ShardRebalance) runnable through a special interface. Docs.

You can run a Background Task (but probably should not  - it's a system action) by calling:

set parms("ClassName") = "Sample.Person"
set tSC = ##class(%CSP.UI.System.BackgroundTask).RunTask("RebuildIndices", "SAMPLES", .parms, .job)

As HIHLib.Support.GetHL7MessageStat:ISBListingQuery is not on the list you can't run it as a Background Task, but you can run it as a Job.

Next - no output. Note that you do not specify these parameters:

principal-input Principal input device for the process. The default is the null device.
Principal output device for the process. The default is the device you specify for principal-input or the null device if neither device is specified.
UNIX®: If you do not specify either device, the process uses the default principal device for processes started with the JOB command, which is /dev/null.


Only one process can own a device at a time. This means that a job executing in a JOB Server is unable to perform input or output to your principal I/O devices even though you may close device 0.

So by default you run your job with stdio set to /dev/null and that's why there's no output.

You can either pass a device to write output to or write a wrapper which would handle the output and job that.

Background tasks are an internal feature mostly for System Management Portal, and in most cases also not supposed to be called by you.

JOB, is a complete different story. with this command, you have control over many aspects of how to run this process in the background. 

You can check $Test, (be careful, and do right after JOB) which says if your process even started in the background

$ZChild returns that job ID, you can check it in SMP if it's running

$Data(^$JOB(child)) will say if your child process is still alive.

You may have up to 25 (can be less) background jobs per process. So, store the child process ID after each call of JOB command

You may redirect output from that process to some file, by passing principal-output parameter

With ^$JOB and $ZChild, you at least can wait until the process is finished its work. With an endless loop and reasonable HANG 

And if you find the job is starting (from evidence provided by $T and $ZCHILD) then ensure you have an error trap in your class to catch why it's falling over. At the very least make it Set ^tempGlo($H)=$ZE or DO ^%ET when it encounters an error.

If you can't edit the class for any reason then JOB a routine that you can edit and make that call your class after setting up an error trap.

Thanks everyone for your help and advice.

The 'screen' command on Redhat turns out to be what works well for the moment. We just moved from desktops to laptops and instead of using WVD to connect from home, we now use VPN to connect to the network. 

I will still play around with the JOB command.

The processes I am running will become scheduled tasks eventually but we are still trying things out for the near future.

Thanks again!