Just create a "job wrapper" around the function, then JOB the subroutine:

JOBEXPORT ; SET UP A ROUTINE TO EXPORT A FILE.
 Q ; USE SEPARATE ENTRY POINT, JUST IN CASE...
 ;
SAVE ; HERE'S THE ACTUAL SUBROUTINE TO EXPORT THE ROUTINE.
 ; IT THROWS AWAY ANY I/O, MAYBE YOU DON'T WANT THAT.
 D $SYSTEM.OBJ.Export("RTOSAVE.INT","E:\Z\SAVEDROUTINE.RTN")
 Q
 

Then, just JOB the subroutine and get the job number:

JOB SAVE^JOBEXPORT SET CHLD=$ZCHILD WRITE CHLD,!

( This prints the child process ID, if you don't need to see it you can omit the last WRITE statement. )

Later, to see if the routine is still working, use the $DATA and $^JOB functions:

WRITE $DATA(^$JOB(CHLD))

If the 0 the job has completed (or possibly crashed, I suppose) - if it's 1 then the task is still running. There are utilities both in the Management Portal and in the %SYS namespace to terminate rogue processes.

Hope this helps!

[[ Edited for minor error in code... there might be more. ]]

If the System File Numbers in question are related to the database files themselves instead of the journal files, there's a query in SYS.Database called "CompactLocalList" that might get you what you need. Note: It seems that the query calls in SYS.Database need to be called from the %SYS namespace.

Try this (ugly, but hopefully useful) code snippet, and see if it gets you what you need:

zn "%sys"
set q = ##class(%SQL.Statement).%New()
set status = q.%PrepareClassQuery("SYS.Database","CompactLocalList")
set rset = q.%Execute()
while rset.%Next() { write !,rset.%Get("Directory"),*9,rset.%Get("SFN") }
w q.%Close()

Here's the documentation page for the SYS.Database class: https://docs.intersystems.com/irislatest/csp/documatic/%25CSP.Documatic.cls?LIBRARY=%25SYS&CLASSNAME=SYS.Database

and this will take you directoy to CompactLocalList.

There's one or two other calls that mention SFN's, so there might be other clues in the documentation referenced above.

Hope this helps!

I noticed that you're using Cache 2018.1. I'd like to just warn you that as of Cache 2017, this functionality was quite broken and InterSystems recommends you not use it. I don't know if it was fixed in 2018 or a later version, so I don't know for sure if your version is affected, but it's something you may want to be aware of.

If the functionality wasn't fixed in 2018, you can still recover the space in the database but it will have to be offline as no modifications to the database can happen during the process. There's a utility named ^GBLOCKCOPY that can copy all of the global database blocks from your existing database to a new one where the new database will only grow as large as necessary thereby reclaiming the free space.

See my answer to this post: https://community.intersystems.com/post/ensemble-2013-compacttruncate

And, here's more documentation regarding the ^GBLOCKCOPY utility: https://docs.intersystems.com/irislatest/csp/docbook/DocBook.UI.Page.cls?KEY=GSTU_remote_gblockcopy

Hope this helps!