...until the new field test version arrived. Links are broken again.

Unfortunately there is currently zero information on what this version delivers. I'm particularly keen to see the Document / JSON database features that were withdrawn from 2016.2 seeing a return. Is anyone from ISC able to share info on this?

Your assertion about % variables being shared across processes is incorrect.  They only exist for the process setting them up. For a given process, once set, they are accessible no matter what namespace the process changes into but that is true for all local variables, not just %.

Re: Caché Release Notes, Other Items of Note: Lightweight SQL Profile

What is that?

Hi Alexey

 Strings longer than a half of a block are not cached on application servers. In reality, this threshold is a bit lower – around 3900 bytes for 8 KB blocks. This decision was made by the developers to keep cache clean of BLOBs and CLOBs: such data is usually written once and is rarely read afterwards.

I believe this ECP caching limitation has been addressed in v2016.1. From the release notes:

Enhanced caching on ECP application servers.  Application servers now cache big string data values.  ECP also automatically prefetches some database blocks and caches them on application servers in advance.

Have you got an example of how to use the Pause and Resume methods?

All the examples I've seen so far use the Queue and WaitForComplete methods, i.e. the process that has access to the workmgr object is waiting for everything to be completed and is therefore not accepting any other signals.

Please find below this test code of mine, using QueueCallBack and Wait methods that allows stopping the work, even if it's not very elegant. But it looks as if the Wait method is waiting for %exit =1 only. How would I suspend / resume?

Class DEV.WK.Tst1 Extends %RegisteredObject
{

ClassMethod Run() As %Status
{
k ^wk.Tst1
s sc=..ManageQ()
q sc
}

ClassMethod ManageQ() As %Status
{
s sc=$$$OK
s queue=$SYSTEM.WorkMgr.Initialize("/multicompile=1",.sc) if ('sc) { s sc=$$$ERROR($$$GeneralError,"Error initialising work queues: "_$system.Status.GetErrorText(sc)) q sc }
for i=1:1:100 {
s startchunk=i*1000,endchunk=((i+1)*1000)-1
s sc=queue.QueueCallback("##class("_$classname()_").Work","##class("_$classname()_").QCallBack",startchunk,endchunk) if 'sc { s sc=$$$ERROR($$$GeneralError,"Error queuing up work: "_$system.Status.GetErrorText(sc)) return sc }
}
s sc=queue.Wait(,.AtEnd) s ^wk.Tst1("AtEnd")=AtEnd
if sc&&'AtEnd { s sc=$$$ERROR($$$GeneralError,"Processing halted") }
d queue.Clear()
q sc
}

ClassMethod Work(StartId As %Integer, StopId As %Integer) As %Status
{
s ^wk.Tst1("work",$j,StartId)=""
h 60
q $$$OK
}

ClassMethod QCallBack(StartId As %Integer, StopId As %Integer) As %Status
{
if $d(^wk.Tst1("work",%job)) { s ^wk.Tst1("work",%job,StartId)=1 }
if $g(^wk.Tst1("halt"))=1 { s %exit=1 }
q $$$OK
}
 

ClassMethod Halt() As %Status
{
s ^wk.Tst1("halt")=1
q $$$OK
}

}

Which Monday is that Kyle?

Can I confirm that it is possible to set up a mirror with an async reporting mirror member only, i.e. I'm not interested in mirroring as a fail-over mechanism (in this specific context). I just want a reporting server with production data that serves ad-hoc queries instead of these queries being run directly against my operational data processing engine.

Further, can you please tell me why I would chose an async mirror over shadow journalling? 

Hi Kyle

When / why would I chose an iFind index over a full text index

INDEX MissionKW ON Mission(KEYS) [ TYPE=BITMAP ];

that I can search via SQL as such

SELECT * FROM Sample.Company WHERE Mission %CONTAINS ('agile')

That SQL code seems a lot more intuitive then the one one required by iFind where I have to know the index name.