go to post Pete Greskoff · Dec 16, 2016 What version of Windows are you running? I was able to install Cache for Windows (x86-64) 2017.1 (Build 726U) Thu Dec 8 2016 22:41:57 EST on Windows 7 (Ensemble installation). It was an upgrade from a previous version. It would be worth looking at the Windows event log to see if there were errors in there. If you don't get an answer here quickly, I suggest opening up a WRC issue.
go to post Pete Greskoff · Nov 22, 2016 You aren't actually writing a response. To get the result in the terminal, you'd need to 'write' the output instead of 'do'.
go to post Pete Greskoff · Nov 9, 2016 This means that the SuperServer spawned a child job to handle incoming connections (this is what happens when any incoming connection comes to the SuperServer). After this child job starts up, it tried to read the connection information from the client, but the message wasn't there. This could be caused either by a slow network or by something that's simply attempting to connect to the SuperServer but not actually making a real connection (possibly testing that port). I would take a look at that IP address (10.251.10.16) to see what that is. My best guess is it's some sort of monitoring software if all 4 servers report the same IP address in their errors.
go to post Pete Greskoff · Nov 1, 2016 You need the %All role to run this, per the following documentation: http://docs.intersystems.com/latest/csp/documatic/%25CSP.Documatic.cls?P...
go to post Pete Greskoff · Nov 1, 2016 Note that this was reported to Wireshark a few months ago, and they said they would update their installer such that it avoids this Microsoft bug. I haven't updated Wireshark recently, but I believe they've already implemented this for their latest versions.
go to post Pete Greskoff · Oct 25, 2016 This should be scripted to be done as part of the cluster failover process, much in the same way you previously had it configured to be scripted on system startup.
go to post Pete Greskoff · Oct 19, 2016 It's likely that you didn't actually export the SQL Privileges. You can do that via ^SECURITY -> System parameter setup -> Export All Security settings. This will allow you to specifically export just SQL Privileges records if you answer 'no' to 'Export ALL security records?'
go to post Pete Greskoff · Oct 11, 2016 If all you're really looking to do is shut down the instance, you can do this with a $zf(-2) callout to the OS to call 'ccontrol stop <instance> quietly restart' (or 'ccontrol stopstart <instance>' if you are on Windows). Do not use $zf(-1) for this, as shutdown would wait for the $zf(-1) calling process until reaching the ShutdownTimeout value. See this doc for an example of using $zf(-2):http://docs.intersystems.com/latest/csp/docbook/DocBook.UI.Page.cls?KEY=...
go to post Pete Greskoff · Sep 23, 2016 Caché should always be shut down separately before the OS is shut down, and that would completely avoid this issue, allowing Caché to go through its normal shutdown procedure.
go to post Pete Greskoff · Aug 29, 2016 Mirrored databases also need to be journaled, so if you are running a mirrored environment, consider whether you need the data to exist (and be consistent) after a failover or not. If not, you could make that particular database non-mirrored and disable journaling for it.
go to post Pete Greskoff · Aug 29, 2016 Mirrored databases also need to be journaled, so if you are running a mirrored environment, consider whether you need the data to exist (and be consistent) after a failover or not. If not, you could make that particular database non-mirrored and disable journaling for it.
go to post Pete Greskoff · Aug 18, 2016 Are you actually making any changes to the data? If so, you should use a read-write reporting async. If not, it'd be useful to know the exact errors you're getting.
go to post Pete Greskoff · Aug 15, 2016 One important question when investigating these types of problems: is it one process, a couple processes, or many processes making the majority of these entries? You can find this out by viewing the file, either in the Management Portal or via JRNDUMP. More frequently than not, it's simply one runaway process, and it's quite either to either just terminate it, or at least determine what it's doing by inspecting the process itself.
go to post Pete Greskoff · Aug 5, 2016 You should not be using $zu calls directly, as these are internal and subject to change. As Alexander suggested, you should use $zf(-1) (or $zf(-2))
go to post Pete Greskoff · Jun 8, 2016 It sounds to me that something could be wrong with the parent process of the one you are trying to kill. If you haven't already, I strongly suggest opening a WRC issue for this. It would be worth trying to get a trace (ltrace or strace) of both this process and the parent to see what is going on at the OS level.
