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.
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))
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.
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.
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.
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.
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.
At this point, I suggest opening a WRC issue.
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.
You aren't actually writing a response. To get the result in the terminal, you'd need to 'write' the output instead of 'do'.
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.
If it even got far enough to start an install, there would be a file in C:\Windows\ with a file name starting with CacheInstall
I have the same as John. This is what my 'Overview' tab looks like in the 'Settings' section. These are the only things I have checked off.
Thanks Evgeny. I unchecked the digest mode, and checked 'On comments'. For what it's worth, I had neither 'On updates' nor 'On comments' checked before, yet I would get e-mails with both (I do want them for comments). Maybe the problem was having digest mode.
Thanks Bob. I added that reference to the list.
Do you have a local instance installed that you want to connect to? If so, the IP would be 127.0.0.1 (or localhost). You shouldn't need to configure the others unless this is a specialized instance setup. If you simply installed a development instance and are using that version of Studio, there is nothing you need to actually setup. As for the docs, maybe this section will be better. It also may be useful for you to start with the Using Caché Studio book.
Yes, you can, you just need to run another installation. It will automatically use different ports, as it is aware of other instances on the system.
Why do you need to do this? I don't believe it's possible to define global node types. If your application is parsing this data, you could just use '+^a("1.0011")' if you know it is going to be stored as a number. EX:
%SYS>s x = ""
%SYS>w +x
0
The CA server does not have to be one of the mirror members. The example you suggest is valid.
Larry, you probably want to open up a WRC issue to address this. The first step will be to try to figure out if the problem is with Caché or with the operation specifically. To do so, you'll want to try to make this connection in a terminal. If any of these statuses are not successful, you should 'd $system.OBJ.DisplayError(<variable>)' and collect the local file you set up with the trace mask:
set ssh=##class(%Net.SSH.Session).%New()
do ssh.SetTraceMask(511,<newlocalfile>)
s st1 = ssh.Connect("<SFTP HOST>","22")
s st2 = ssh.AuthenticateWithUsername("<UserName>","<Password>")
s st3 = ssh.OpenSFTP(.sftp)
s st4 = sftp.Put("<local path and filename","<remote path and filename>") If Bob's suggestion doesn't fix your problem, I recommend opening up a WRC issue about this. In addition to the encryption keys, you could have an issue with the SSL setup (SSL is required for mirrors if you're using journal encryption). For what it's worth, you could take a look at my article about creating an SSL-enabled mirror with keys/certificates generated using the Public Key Infrastructure to see if that helps.
Also, even if SSL is set up correctly, you still need to accept the async's connection from the primary server. Did you do that?
It could be related but maybe not. I definitely suggest contacting the WRC about this.
That would work, but I'd suggest creating different ones so you can distinguish between the members.
Again, I suggest opening a WRC issue to address this. The first step will likely be to enable REDEBUG (do ^REDEBUG in %SYS and set the new value to FFFFFFFF). Then you will disconnect from the mirror (^MIRROR -> Mirror Management -> Disconnect), then connect again. Then set REDEBUG back to FF and collect the cconsole.log for the WRC as well as the cconsole.log on the primary. I must ask again if you added the async as an authorized async on the primary, as that is required to connect if using SSL.
Yes, after you've already set up SSL for each member, you can enable it as you suggested. The primary will force the other members to disconnect, and, assuming the SSL setups are correct, those members will rejoin using SSL.
csession for Windows was added in 2017.1, so that explains why you do not have it.
I should also note that the data in the CACHE database is not completely ignored at startup (if it is there), as is the case for CACHETEMP. No matter what is in CACHETEMP when Caché starts up, Caché treats it as if it is empty.
As far as ECP is concerned, you are only creating remote DATABASES. You can map 1 NAMESPACE on a system to point to any databases it has configured, local or remote. You could easily have app server instance A connect to both data server instances B and C and create a remote database for each of them. You could then have 1 namespace on A use the databases from B and C for various things (globals, routines, specific mappings).