Without research It is hard to say what might have caused this.  Definitely something you should open with support if it keeps happening.

For completeness I'm adding below the steps to check on the status of the task manager and how to start or resume it if necessary:

In cache terminal:

%SYS>d ^TASKMGR 

1) Create a Task
2) Edit a Task
3) List Tasks
4) Delete a Task
5) Suspend a Task
6) Resume a Task
7) Run a Task
8) Task Reports
9) Task Manager Options
10) Exit
 
Option? 9
 
1) Task Manager Information
2) Start Task Manager
3) Suspend Task Manager
4) Resume Task Manager
5) Task Manager History
6) Define Mail Settings
7) Exit
 
Option? 1
Task Manager Version: 2.9
Task Manager is currently suspended
Task History purged after 7 days
 
1) Task Manager Information
2) Start Task Manager
3) Suspend Task Manager
4) Resume Task Manager
5) Task Manager History
6) Define Mail Settings
7) Exit
 
Option?  <---Here you can choose to resume or start the task manager depending on the status from the Task Manager information returned in the step above.

For client certs to be sent to the LDAP server one needs to wrap a given cert and its associated private key into a PKCS
#12 file and import that into the Personal Certificates certificate store.  This can be done with the OpenSSL pkcs12 command.  Below is a document I on  how to perform this process:

Importing Certificates to a Windows Certificate Store

1. Convert the certificate from PEM format to PKCS#12 format.

e.g. C:\demoCA\newcerts>openssl pkcs12 -export -in newcert.pem -inkey "..\newkey.pem" -out newcert.pfx -name "New Certificate"

Loading 'screen' into random state - done

Enter pass phrase for ..\newkey.pem: <hidden>

Enter Export Password: <hidden>

Verifying - Enter Export Password: <hidden>

1. Add the Certificates Snap-in to the Microsoft Management Console
   1. Start->Run->”mmc”
   2. File->Add/Remove Snap-in
   3. Add…->Certificates->Add
   4. For client and client-side CA certificates select ‘My user account’; for server and server-side CA certificates select ‘Computer account’->’Local computer’.  Finish.
   5. Close->OK

1. Import the certificates to the appropriate store

1. For client certificates, navigate to ‘Certificates – Current User’->’Personal’->’Certificates’
2. Right-click to select All Tasks->Import
3. Specify the certificate, enter the private key password (the “export password” from step 1 above) if applicable and specify ‘Personal’ as the certificate store.
4. For client-side CA certificates navigate to ‘Certificates – Current User’->’Trusted Root Certification Authorities’->’Certificates’ and repeat steps b and c.
5. For server certificates navigate to ‘Certificates (Local Computer)’->’Personal’->’Certificates’ and repeat steps b and c.
6. For server-side CA certificates navigate to ‘Certificates (Local Computer)’->’Trusted Root Certification Authorities’->’Certificates’ and repeat steps b and c.

You may want to open a WRC issue for this since the route to failure is not well understood based on the details in the question.  It is possible for a tied terminal session to change namespaces.  For instance, I created the following routine in %SYS:

TestTerminal ;test what happens when switching namespaces
         w !,"I am in %SYS",!
         d THIS^%SS
         h 5
         ZN "USER"
         w !,"Now I am in USER" 
         d THIS^%SS
         h 5
         q

I called this routine from a command prompt like so:

c:\C2K16\bin>ccontrol cterminal C2K16 TestTerminal %SYS

This popped up a terminal window which ran the routine producing the following output:

I am in %SYS
                   Cache System Status: 10:43 am 12 Dec 2016
 Process  Device      Namespace      Routine         CPU,Glob  Pr User/Location
    2092                             CONTROL           0,0     8
    2248                             WRTDMN           50,366   9
    2256                             GARCOL            0,0     8
    2268                             JRNDMN       175139,0     8
    2276                             EXPDMN            0,0     8
    3972  //./nul     %SYS           %SYS.TaskSuper
                                                 2247760,90501 8  TASKMGR
    3096  //./nul     %SYS           MONITOR      941163,87    8
    3240  //./nul     %SYS           CLNDMN        20530,1179  8
    3016  //./nul     %SYS           RECEIVE      605864,31894 8
    3656  //./nul     %SYS           ECPWork           0,0     8  ECPWORK
    3224  |TCP|1972   %SYS           %SYS.SERVER       0,0     8
    4004  //./nul     %SYS           LMFMON        18319,31    8
    6992  |TCP|RRAEL5550:1972
                      %SYS           %SYS.BINDSRV 329537,34024 8  UnknownUser
    3152* |TRM|:|3152 %SYS           %SYS.ProcessQuery
                                                    8889,110   8  UnknownUser
    3680  //./nul     %SYS           %SYS.Monitor.Control
                                                68980082,1191614
                                                               8
 
3 user, 12 system, 1024 mb global/33 mb routine cache
 

Now I am in USER
 
                   Cache System Status: 10:43 am 12 Dec 2016
 Process  Device      Namespace      Routine         CPU,Glob  Pr User/Location
 
0 user, 0 system, 1024 mb global/33 mb routine cache
 
 
 
As you can see the namespace switch happened and the routine ran to completion, so it is possible to switch namespaces within a tied terminal routine.

Thoughts on the specifics of what might have failed for your process.

1. Were you trying to quit out of the routine to get into programming mode?  You cannot exit from a tied terminal session (one that enters cache calling a routine) to a programming mode session.  When the routine quits the terminal session exits.

2. After execution the terminal screen will exit.  Was the work done in that second namespace something that you would expect to see output from, or have to enter text to a read command?  or would it run fast and then quit?  IE, did the work get done, but you not see it?

3.  Do you have error trapping in your routine in that namespace, and did an error get trapped.  This may help understand the behavior.

If this is not helpful please open a WRC issue and get help from support in addressing your issue.
 

You can also use %XD and %DX if you want something that prompts:

USER>d ^%XD
 
Hex: FFF        Decimal: 4095
Hex:
 
USER>d ^%DX
 
Decimal: 1240       Hex: 4D8
Decimal:
 

The Documentation that Eduard provided has all of the details for installing cache, but the simple answer, for someone looking for a quick tip is here:

We provide distribution packages available on our distribution page:

https://wrc.intersystems.com/wrc/Distribution.csp

Login in with your wrc direct account and download the package that is the correct version you want, and that is correct for your operating system.  The packages are named such that their version on os should be clear.

Windows:  The package will be an executable like so:

cache-2016.1.0.656.0-win_x64.exe

Download this to a location on your system that is not in the pathway where you want to install.  Double click and it will start the installation wizard.  From there is will prompt with questions you answer about how you want to install cache.  If you are not sure of some of those answers the document that Edward pointed out will have lots of answers.  When the installation is complete there will be a blue cube on the dashboard from which you can access cache.

Unix and Mac:  The package will be a zipped tar file like so:

cache-2016.1.0.656.0-ppc64.tar.gz

Download and place in a pathway where you are not installing cache.  Unzip this with:

#gunzip cache-2016.1.0.656.0-ppc64.tar.gz

then untar it like so:

#tar -xvf cache-2016.1.0.656.0-ppc64.tar

When done it will expand several files that are part of the distribution.  Start the installation script like so:

#./cinstall

It will prompt you with answers to questions about the install.  If you have questions about this you can refer to the documentation that Edward posted.  When done it will tell you the url to use to access the instance with the system management portal.  You can use csession <instance name> to get into cache.

vms:  This is similar in install to unix, but opening the kit up is a bit different.  The package will be a bck file like so:

cache-2016.1.0.657.0-alphavms.bck

Set the attributes of the file correctly so that it can be opened:

$ SET FILE/ATTRIB=(RFM:FIX,LRL=32256) cache-2016.1.0.657.0-alphavms.bck

expand the bck file like so:

backup cache-2016.1.0.657.0-alphavms.bck/save DISK:[dir...]

Note, you will have to put the appropriate disk and directory designation.  The ... following the directory name is necessary so that it properly expands the directories.  You will have to get into the directories that it creates to get to the cinstall executable.   There type @cinstall in order to start the installation.  Again it will prompt for answers just like with unix.

Hope this helps.

You can enable auditing and audit of logins so that the login events can be examined.  Are they logging in as the same user?

The TryCache instance name indicates this is the single user version of Cache and will not allow a license to be installed.  What is the exact $ZV?

If you have a license that you would like to work with then download a full installation and add the license to that.

What was the issue number here at intersystem where you were not getting the help you needed.  I'll check that out and see if there is further I can ad.

Hi Glenda,

Don't know if you already opened an issue with the WRC about this, but I wanted to include something that might be helpful to you or others with similar issues.

When dealing with SSL/TLS issues it is helpful to use our REDEBUG routine to gather more information into the cconsole.log file:

%SYS>d ^REDEBUG
Old flag values = FF
 New flag values (in Hex): FFFFFFFF
 

You actually enter eight capital F's to set the REDEBUG flags.  This will cause a lot more logging of networking related messages into the cconsole.log file.  Most are useless/info only so we don't normally run with the flags set; it would fill up the log file to quickly.

After setting these flags reproduce whatever issue you are having.  In this case test the SSL/TLS connection.

Lots of new messages about the connection will be logged in cconsole.log, and these may be helpful to you to diagnose further, and may be required by Intersystems support in order for them to diagnose the issue.  Might as well get this to provide upon opening an issue so that there is less delay for an answer.

When you are done reproducing the issue please set the REDEBUG flags back so that you don't fill the cconsole.log:
 
%SYS>d ^REDEBUG
Old flag values = FFFFFFFF
 New flag values (in Hex): FF
 
Hope you find this helpful.
 
%SYS>

Here is an example of using cvendian to convert the endian of a CACHE.DAT file:

c:\C2K1522\bin>cvendian

Usage:  cvendian [-option] file1 [file2 ... file8]

        -option = -b[ig], -l[ittle], or -r[eport]

Note:  Running without an argument shows you usage

c:\C2K1522\bin>cvendian c:\C2K1522\mgr\user\CACHE.DAT
This database is little-endian.
This database has a block size of 8192 Bytes.

This database has 1 map.
The last block is 18432.

Original manager directory is c:\c2k1522\mgr\user\
18000 blocks (97%)
Done converting c:\C2K1522\mgr\user\CACHE.DAT to big-endian

c:\C2K1522\bin>

Note:  cvendian is an executable in the bin directory of you cache installation

The CACHE.DAT file should be dismounted before cvendian is run against it.

Also, if you do not know the endian of your two machines you can check fairly easily in cache like so:

%SYS>D ^%ST w %ST("indian")

It will display a 1 or a 0 depending on the endian of the system.  Systems with matching endians do not need a conversion to be run in order to use each others databases