Bypass is easy, and I've already suggested it in my initial post. As to use cases... maybe I'll describe them later. The method of journal switch detection is not critical for them.
Agree with you, parsing terminal output is not the smartest solution. I always try to avoid it using intermediate files. E.g. (from real life):
rm -f $mydir/db_temp
NspToCheck=$nspace
csession $instance -U%SYS << EOF > /dev/null
set fn="$mydir/db_temp"
o fn:("WNS"):1 u fn
try {
zn "$NspToCheck"
w \$s(\$zu(5)=\$zcvt("$NspToCheck","U"):\$zutil(12,""),1:"$NspToCheck")
} catch {
w \$p(\$ze,">")_">"
}
c fn
h
EOF
DbQms=$(cat "$mydir/db_temp")
Here the default DB of the namespace $NspToCheck (or $ZError code) is written to $mydir/db_temp file, than it goes to $DbQms shell variable and processed as needed.
After cheching my großbuch I found that I was wrong with starting version: $zf(-100) is available since 2017.2.1 (Build 801_3), while your build hasn't got this "_3" suffix.
You mentioned earlier that switching to Direct I/O would slow down Caché On-line Backup; it sounded strange for me: if database I/O and journal I/O can use different strategies, why On-line Backup can't always use buffered I/O regardless of database I/O strategy?
I use the similar code for the same purpose and it works. Here is my (debug) version has been written awhile ago:
; In:
; pFirst - 1st journal file,
; pLast - last journal file,
; pSDB - source DB directory where journals were generated,
; pTDB - target DB directory where journals should be applied
;
; Sample:
; zn "test" set target=$zu(12,""), source=target ; start in target namespace assuming source == target
; k ^mtempfilt ; if you injected your ZJRNFILT
; d jrnrest^ztestFF("20190917.001","20190919.008",source,target)
; zwrite ^mtempfilt
;
jrnrest(pFirst,pLast,pSDB,pTDB)
new (pFirst,pLast,pSDB,pTDB) ;de!!!
new $namespace s $namespace="%SYS"
s pLast=$g(pLast,pFirst)
s pSDB=$g(pSDB,$zu(12)_"user\")
s pTDB=$g(pTDB,$zu(12)_"test\")
s RestOref=##class(Journal.Restore).%New()
s RestOref.FirstFile=pFirst
s RestOref.LastFile=pLast
s RestOref.RollBack=0 ;? default = 1
w !,pFirst_" to "_pLast_"; "_pSDB_" => "_pTDB_" OK?" r ans#1 w ! quit:"nN"[ans
s sc=RestOref.RedirectDatabase(pSDB,pTDB) if 'sc g jrnbad
s sc=RestOref.SelectUpdates(pSDB) if 'sc g jrnbad ; all globals; need it to fire RedirectDatabase
s RestOref.Filter="^ZJRNFILT1" ; means nothing as ^ZJRNFILT is always used
s t0=$zh
s CHATTY=0 ; has no effect
s sc=RestOref.Run() if 'sc g jrnbad
s t1=$zh
w "sc="_sc_" dt="_$fn(t1-t0,"",3),!
jrnbad
if $g(sc)'="",'sc d $system.Status.DisplayError(sc)
quit
Hi Alexander,
Bypass is easy, and I've already suggested it in my initial post.
As to use cases... maybe I'll describe them later. The method of journal switch detection is not critical for them.
Thank you anyway.
It needs Unicode characters as well, otherwise it fails. Just compare 8 bit instance run:
with Unicode one:
Hi James,
Agree with you, parsing terminal output is not the smartest solution. I always try to avoid it using intermediate files. E.g. (from real life):
rm -f $mydir/db_temp NspToCheck=$nspace csession $instance -U%SYS << EOF > /dev/null set fn="$mydir/db_temp" o fn:("WNS"):1 u fn try { zn "$NspToCheck" w \$s(\$zu(5)=\$zcvt("$NspToCheck","U"):\$zutil(12,""),1:"$NspToCheck") } catch { w \$p(\$ze,">")_">" } c fn h EOF DbQms=$(cat "$mydir/db_temp")Here the default DB of the namespace $NspToCheck (or $ZError code) is written to $mydir/db_temp file, than it goes to $DbQms shell variable and processed as needed.
Initial answer was amended.
I'm confused a bit. Do you keep asking on this issue? If not, please describe your situation in details.
Sorry, didn't mentioned your *new* quesion about environment variables.
After cheching my großbuch I found that I was wrong with starting version: $zf(-100) is available since 2017.2.1 (Build 801_3), while your build hasn't got this "_3" suffix.
Zdeněk,
I'm just curious: are you intentionally testing $zf() stuff on command (`pwd`) that doesn't exist in your particular OS?
Hi Murray,
Thank you for responding.
You mentioned earlier that switching to Direct I/O would slow down Caché On-line Backup; it sounded strange for me: if database I/O and journal I/O can use different strategies, why On-line Backup can't always use buffered I/O regardless of database I/O strategy?
Murray,
Do you recommend this setting (wduseasyncio=1) for production as well? If it slows down all disk i/o, what will happen with journaling?
I use the similar code for the same purpose and it works. Here is my (debug) version has been written awhile ago:
; In: ; pFirst - 1st journal file, ; pLast - last journal file, ; pSDB - source DB directory where journals were generated, ; pTDB - target DB directory where journals should be applied ; ; Sample: ; zn "test" set target=$zu(12,""), source=target ; start in target namespace assuming source == target ; k ^mtempfilt ; if you injected your ZJRNFILT ; d jrnrest^ztestFF("20190917.001","20190919.008",source,target) ; zwrite ^mtempfilt ; jrnrest(pFirst,pLast,pSDB,pTDB) new (pFirst,pLast,pSDB,pTDB) ;de!!! new $namespace s $namespace="%SYS" s pLast=$g(pLast,pFirst) s pSDB=$g(pSDB,$zu(12)_"user\") s pTDB=$g(pTDB,$zu(12)_"test\") s RestOref=##class(Journal.Restore).%New() s RestOref.FirstFile=pFirst s RestOref.LastFile=pLast s RestOref.RollBack=0 ;? default = 1 w !,pFirst_" to "_pLast_"; "_pSDB_" => "_pTDB_" OK?" r ans#1 w ! quit:"nN"[ans s sc=RestOref.RedirectDatabase(pSDB,pTDB) if 'sc g jrnbad s sc=RestOref.SelectUpdates(pSDB) if 'sc g jrnbad ; all globals; need it to fire RedirectDatabase s RestOref.Filter="^ZJRNFILT1" ; means nothing as ^ZJRNFILT is always used s t0=$zh s CHATTY=0 ; has no effect s sc=RestOref.Run() if 'sc g jrnbad s t1=$zh w "sc="_sc_" dt="_$fn(t1-t0,"",3),! jrnbad if $g(sc)'="",'sc d $system.Status.DisplayError(sc) quit