New post
Question
· Jun 14, 2018

How to get rid of JRNREST annoying questions?

#API #Journaling #Object Data Model #Caché

I am still working on a generic task where I need to apply journal file records to another database. Initially I didn't want to use Journal.Restore class methods as I need to perform some data transformation, and it seemed that the clearest way to achieve it was to read journal file record by record using %SYS.Journal.Record API. 

This approach worked (with some help from @Dmitry Maslennikov and @Eduard Lebedyuk), while it turned that the processing speed of %SYS.Journal.Record:List query was very slow, about 1MB of journal data per second on a mid-range server.

Therefore my second try was to adapt Journal.Restore class to my needs. As you surely know, this class has got Filter property that allows setting up ZJRNFILT routine for granular processing of selected records. OK, it works, and seems to be several times quicker than %SYS.Journal.Record:List, but the new problem I faced is that it turns on interactive mode of journal restore, asking my if I want to rename the routine, etc - just as when this facility is used with interactive ^JRNRESTO utility. Running my code with JOB command didn't help.

These nasty questions can ruin the idea as I need completely non-interactive solution to run it with JOB command, e.g., using Task Manager.

Cache 2017.2.1.801.3.

Any help would be greatly appreciated.

Discussion (8)1
Log in or sign up to continue
Alexey Maslov · Jun 16, 2018

The solution I've found is rather simple than smart: to start a dejournalizer as a JOB with an 'answer file' specified as a principal-input device. The code prototype looks like this:  

 set fin=$zu(12)_"Temp\fin.txt"
 set fout=$zu(12)_"Temp\fout.txt"
 open fin:("NW"):1 if '$t {write "not opened!",! quit}
 use fin write "N",!,"N",!,"Y",! close fin
 job jrnrest^ztestFF("20180614.006"):(::fin:fout):1 if '$t { w "not started!" q}

Its execution resulted in "fout.txt" file like this: 

20180614.006 to 20180614.006; c:\intersystems\cache\mgr\user\ => c:\intersystems\cache\mgr\test\

Do you want to rename your journal filter? o
Do you want to delete your journal filter? o


c:\intersystems\cache\mgr\journal\20180614.006
   8.88%  14.29%  15.26%  16.79%  18.08%  19.31%  20.35%  21.32%  ....
***Journal file finished at 16:39:36
Do you want to rename your journal filter? es
Journal filter ZJRNFILT renamed to XJRNFILT


[journal operation completed]

"o" and "es" were provided by the auto-completion of "N" and "Y" answers.

Cons of this approach is that ISC can change the ^JRNRESTO dialog in some future version.
Pros: no need in reverse engineering of ^JRNREST stuff to derive a non-interactive journal restore utility.

Hope my writing will be useful for somebody besides myself. Happy coding!

3 0
Alexey Maslov · Aug 28, 2019

Another part of my solution was published as a comment here.

This trick with answers (fin.txt) and messages (fout.txt) files was possible with background job only as only this kind of Caché processes allows the separation principal-input device from principal-output one.

Controlling the execution state would not be so easy in this case as fout.txt is kept opened during the execution of JRNREST. I partially bypass this limitation looping my dejournaling activity for each journal file I need to restore and feeding JRNREST with only one file on each iteration  (pLast = pFirst); so it's possible to report the restore state of each file that has been restored with very modest delay as the restoration of one journal file is usually a quick process.

HTH and happy coding to you!

0 0